|
|
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
Page 4 of 6
The above approach works well when comparing any custom tag library to JSTL. If JSTL fully supports the same functionality, use the standardized JSTL tags. If JSTL tags fail to support some important features you use in these other tag libraries, there is no reason to change to JSTL. In most cases, as I described in my use of Struts and JSTL tags above, you will probably use a mixture of JSTL tags and other tag libraries.
See Resources for links to more details about JSTL, its advantages, and how to use JSTL in your JSPs. The Resources section also contains a link to Apache's Jakarta Standard Taglib, an open source and widely used JSTL implementation. Web server vendors have begun to deliver JSTL implementations with their Web servers, and JSTL is anticipated to be an integrated part of the final JSP 2.0 specification.
While servlet filters were actually introduced as part of the Servlet 2.3 specification, these filters benefit JSP development and maintenance as well. Because JSPs are converted into servlets and are highly coupled with servlet technology, it shouldn't be surprising that significant advancements in the servlet specification often impact JSP development.
Servlet filters are the J2EE implementation of the Intercepting Filter pattern and thus provide the advantages associated with this pattern. These advantages include better maintainability, reduced code redundancy, and greater portability. Servlet filters offer these advantages because many required services that you would normally need to add to each JSP you can instead place into a single servlet. The JSPs do not even need to be aware the filter exists. This lack of coupling between pluggable filters and JSPs means that any changes to the filters will not directly impact the JSPs themselves. You can chain filter servlets, enabling mixing and matching of different filters, each designed for specifically different purposes.
Two examples illustrate the usefulness of servlet filters in JSP-based Web applications. In many security configurations, each JSP checks the session ID or some other security credential to authenticate the JSP's caller. You can move the code for performing this check out of each JSP that makes the check and into a single servlet filter invoked before each JSP executes. Moving the redundant security code out of each JSP and into a single servlet filter significantly improves the JSPs' maintainability and portability. You likely only need to make changes or additions to security-related code in the single servlet filter and not in each JSP. If an entirely different security mechanism is chosen in the future, the servlet filter is the only piece of the system you must replace. The individual JSPs would require no changes.
In the previous "JSP Best Practices" article, I recommended storing exception information in some type of secondary storage and only providing the user with
an identifier to search the storage for the entire exception trace. A servlet filter is very useful in this situation. You
can configure a Web application (via the web.xml file) to automatically execute a servlet filter that logs exception information whenever the exception JSP is called. This
allows a presentation-oriented exception page with all the processing and storage code placed in the intercepting filter.
Archived Discussions (Read only)