Recent articles:
Popular archives:
Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can,
or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing
heavily in Java's future as a platform for platforms
Also see:
Discuss: Tim Bray on 'What Sun Should Do'
Modularization and composition are perhaps the two most important features we have come to rely on in every modern programming environment. Server-side Java Web development technologies offer several means to decompose an application into reusable units. But encapsulating and reusing frontend logic remains one of the most challenging aspects of Web application design. Custom tags constitute one way of encapsulating presentation logic and reusing it within JavaServer Pages (JSP) pages. However, they have several notable disadvantages such as requiring a fair amount of Java programming expertise as well as recompilation and redeployment upon change. Usage of the standard server-side include mechanisms is more common. Includes are more accessible to Web authors and often appear as the more practical solution even to experienced Java developers. Still, the reuse usually achieved through includes rarely goes beyond the simple, macro-like textual level.
In this article, I present a simple technique that enables treating JSP pages and servlets as self-contained, reusable presentation modules. While it opens new and interesting possibilities for decoupling large Web applications, it does not appear to be widely adopted. Based on the dynamic include mechanism of the Java Servlet and JSP specifications, the technique can be viewed as a pattern in the context of Web programming or as an implementation of the general calling frame pattern found in nearly all modern programming languages. I introduce a small API and tag library you can use in your own Web applications. For simplicity, I will use the general term dynamic resource to refer to both JSP pages and servlets.
Note: You can download the source code that accompanies this article from Resources.
Recall that there are two basic means of including one JSP page from another: the <@include file="..."> directive and the <jsp:include page="..."> standard action. The include directive performs a translation time include of the specified file's textual content. It can be considered simply as a type
of macro facility. The include action, on the other hand, invokes the specified server-side resource at runtime. From a programming perspective, it is a
form of a procedure call. For more on the differences between static and dynamic includes, please see Resources.
Yet, to truly treat a JSP page or servlet as a standalone piece of logic, we would like to view it as a user interface (UI) component that can be configured and invoked to render itself. The invocation part is already handled by the dynamic include mechanism. Configuration is the trickier part. Because the dynamic include is implemented as a separate server-side request, you can always append a query string to the Uniform Resource Identifier (URI) and pass request parameters as you would do in a normal URL link. The standard include dispatching mechanism scopes the request parameters; the original request parameters are available with include-specific ones taking precedence in the case of a name conflict. However, there are a few limitations:
Archived Discussions (Read only)