|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
So what's wrong with JSP? It depends on the scope of the project. You cannot argue that one of JSP's strengths lies in integrating an existing codebase with an HTML-based presentation layer that is in need of a few dynamic elements. This integration often involves a Java developer hacking some JSP code into a previously authored HTML page.
In larger projects, time constraints often dictate that the HTML and Java be developed in parallel. Here's where JSP begins to show its faults. First, JSP relies too heavily on Java syntax. HTML coders seldom know Java syntax well enough to author JSP pages entirely by themselves. A typical solution is to have the Java developers "rope off" sections of HTML code with comments, to which they will later add JSP code. This approach leaves the door wide open for a complex form of feature-creep known as "Why doesn't it work the way it did when I originally wrote it?" Let's face it, HTML authors want their code touched about as much as Java programmers do, which is to say not at all. Additionally, it can be difficult to test the validity of the HTML depending upon how much the JSP dynamically generates it. This could leave the HTML authors sitting around waiting for the JSP to be inserted before they can even test their work.
You should also be pessimistic about JSP's long-range prospects. If you've ever tried to parse a typical JSP page with an
XML parser, you know that there are elements of JSP (and not incidentally, also of HTML) that are not XML-compliant; for example,
the <%...%> directive. This implies, of course, that current JSP tags are bound to HTML source files. This might not appear to be an
obstacle now, and it won't be for a while. But some day in the future runtime optimizations will lead to XML output from the
server and XSLT transformations on the client browser, and when that day comes all those JSP pages will be relegated to the
seldom-touched recesses of their respective companies' source control systems. Additionally, to date, JSP hasn't been released
under an open source license. Although it is unlikely that Sun will retract support for this technology, companies should
be aware that they are building an extremely visible component of their business upon a technology whose modifications they
have no control over.
For many, the most compelling argument against JSP is its halfhearted attempt at realizing the model-view-controller (MVC) design pattern. This pattern defines an architectural three-way split for an application, separating data elements (the model) from the data presentation (the view) from the manipulation of the data into the presentation (the controller). JSP makes a valiant attempt to live in harmony with this design pattern, but MVC proponents feel that requiring Java code (the controller) in the HTML (the view) is a violation of their beloved pattern. And they're right. JSP 1.1's custom tags eradicate some of this inconsistency, letting you build a library of tags that encapsulate logic and/or data and provide a JSP interface to them. The drawback is that custom tags are tiresome to configure and require a relative mountain of code to develop something you cannot use outside of JSP. Additionally, instead of relying on the Java language's strengths in inheritance, JSP custom tags rely on the Reflection API, which is a relatively inefficient technology. I say inefficient because instead of calling a method directly, Reflection lets you call a Reflection API method that will attempt to construct a reference to the desired method or class. This additional step comprises much of the inefficiency because of the time it takes to dynamically create the reference to the desired method or class.
include expression. It also contains some discussion of custom tags