J2EE(tm) BluePrints: Questions and Answers:

CONTENTS | PREV | NEXT | INDEX

J2EE BluePrints

Questions and Answers - Web Tier

What kind of code should pages created with JavaServer Pages^TM technology (JSP^TM pages) contain ?

When should I use JSP-style comments instead of HTML-style comments?

How can servlets be made more easily distributable?

My JSP page does not reload when I change it. What's going on?

Can JSP pages process forms?

How do I use international character sets?/li>

When should I use a JSP <%@include@%> directive, and when should I use a <jsp:include> action?

1. What kind of code should pages created with JavaServer Pages^TM technology (JSP^TM pages) contain ?

Ideally, JSP pages should contain no code written in the Java programming language (that is, no expressions or scriptlets). Anything a JSP page needs to do with Java code can be done from a custom tag. (For a description of the syntax for JSP technology, see http://java.sun.com/products/jsp/tags/11/syntaxref11.html. A list of technical resources for JSP pages appears at http://java.sun.com/products/jsp/technical.html.)

Advantages of JSP technology that are partially eliminated by expressions or scriptlets include:

Separation of form and function. JSP pages that contain substantial Java code are usually tangles of layout tags (form) and program logic (function). Such files are are difficult to read and still more difficult to maintain. Changes to program logic corrupt the presentation; and worse, changes in presentation often impact program logic, causing new bugs. Separating logic from presentation allows the two to vary relatively independently.
Separation of developer skill sets and activities. JSP pages are a convenient place to divide work between programmers (who focus on system services) and web page designers (who function on layout, page flow, and so on). Web page designers understand how to use tags to create web pages, and usually are less skilled at programming. Java code in a JSP page can make the page tags difficult for a page designer to understand, particularly if it contains a great deal of "if-then-else" logic. Likewise, programmers need to focus on what the system does, without the distraction of presentation tags scattered throughout the code. Placing program logic in custom tags allows programmers to focus on system functionality, and web page designers to focus on content presentation. This separation also enhances maintainability, since programmers will maintain custom tag source code, and designers will maintain the JSP pages. Developers and designers can work more independently, since they will be working with separate source files.
Code reusability. Java code embedded in a JSP page is basically non-reusable. While it is possible to reuse JSP pages with server-side file inclusion or template mechanisms, such reuse is pretty much an all-or-nothing proposition: to get the functionality, you have to take the presentation along with it. But custom tags can be reused in any JSP page, while stylesheets can present the content produced by the tag in any way that the page designer sees fit.
Clarified system design. System design clarity may be the greatest, yet least quantifiable, benefit of separating separating code and layout in a JSP page. The presence of a rule that Java code may not be placed in a JSP page forces system architects and graphic designers to think out what service the a given page is meant to offer. It's easy to fall into the trap of thinking in terms of writing Java code that "produces web pages" (The history of servlets, and CGIs before them, only intensify that assumption.) Avoiding Java code in JSP pages helps the architect remember that the purpose of the code is primarily system functionality -- not "producing pages".

Using custom tags, web applications can (and should) be created in terms of JSP pages with no Java code. Custom tags receive as inputs both the attribute values of the tags, and the contents of the tag body. The custom tag code can use these inputs to create content of arbitrary structure and complexity from any data source.

While we consider JSP pages without Java code to be a true "best practice", you may choose to do otherwise. In that case, try to write only code that relates to the presentation of that particular page. (If data processing logic does appear in the page, ask yourself: Why must this code be here? How could I create a tag that provides this service?) Keep in mind that we strongly recommend against using Java code in JSP pages. We recommend encapsulating all custom logic in custom tags, servlets, or JavaBeans components.

2. When should I use JSP-style comments instead of HTML-style comments?

Always use JSP-style comments unless you specifically want the comments to appear in the HTML that results from serving a JSP page.

JSP-style comments are converted by the JSP page engine into Java comments in the source code of the servlet that implements the JSP page. Therefore, JSP-style comments don't appear in the output produced by the JSP page when it runs. HTML-style comments pass through the JSP page engine unmodified. They appear in the HTML source passed to the requesting client.

JSP-style comments do not increase the size of the document that results from the JSP page, but are useful to enhance the readability of the JSP page source, and to simplify debugging the servlet generated from the JSP page.

3. How can servlets be made more easily distributable?

Many application servers allow the creation of web containers (in which servlets run) in multiple simultaneous Java virtual machines. Servlets are easier to distribute if they are stateless. Servlets that maintain state, yet run in separate virtual machines (on the same machine or otherwise), must be able to access state across virtual machines to satisfy service requests. The overhead involved in communicating that state between servlets in the web tier can somewhat offset the benefits gained by distributing load, since state replication becomes just one more thing the servlet has to do.

4. My JSP page does not reload when I change it. What's going on?

The JSP 1.1 specification does not require dynamic reloading (automatic recompile of modified JSP pages). Many servers cache compiled JSP pages in memory to improve performance, and require some explicit operation (such as an explicit reload, or even a server restart) to reload a changed page.

Another possibility is that the page you changed is used only by way of a server-side include, and the server doesn't dynamically reload included pages. In this case, it may help to "touch" (change the modification date of) the parent file to ensure a dynamic reload. See your server documentation for details on JSP page loading.

A third possibility is that you're not modifying the actual JSP page, but a copy of it somewhere.

5. Can JSP pages process forms?

JSP pages can process forms using Java code embedded in the JSP page (that is, in a "scriptlet"), or from within custom tag code. We do not recommend this approach, for reasons detailed above. We recommend processing forms using servlets that receive the GET or POST data, and then forwarding the request and associated input to the appropriate JSP page.

6. How do I use international character sets?

Multilingual sites commonly use subclasses of java.util.ResourceBundle, combined with property files to manage internationalization. Such sites must be carefully constructed to ensure that encoded files are not corrupted by being handled in locales that do not support the file encodings.

One way around this problem is to use escape sequences or numeric character entities to represent characters in other encodings. For example, the Japanese message "Thank you for your order" appears in the table below represented as Unicode-encoded text, as escape sequences, and as numeric character entities.

Unicode characters
Unicode as escape sequences	`\u5fa1 \u6ce8 \u6587 \u3042 \u308a \u304c \u3068 \u3046 \u3054 \u3056 \u3044 \u307e \u3059 \u3002`
Unicode as numeric character entities	`&#5fa1;&#6ce8;ᦻ௢&#308a; &#304c;௼௦௮௰ ௤&#307e;௳஺`

The benefit of this technique is that a file containing this ASCII representation of the message may be safely moved and viewed in any locale. The main drawback of the technique is these files will always need to be encoded (often by the browser) into the native encoding, even in locales that support the encoding represented by the escape sequences or numeric character entities. Encoding files with escape sequences or numeric character entities also makes them very difficult for a human to read and edit.

The Java Development Kit contains a tool called native2ascii that translates non-ASCII encodings to ASCII escape sequences.

7. When should I use a JSP <%@include@%> directive, and when should I use a <jsp:include> action?

A JSP <%@include@%> directive (for example, <%@ include file="myfile.jsp" @%>) includes literal text "as is" in the JSP page and is not intended for use with content that changes at runtime. The include occurs only when the servlet implementing the JSP page is being built and compiled.

The <jsp:include> action allows you to include either static or dynamic content in the JSP page. Static pages are included just as if the <%@include@%> directive had been used. Dynamic included files, though, act on the given request and return results that are included in the JSP page. The include occurs each time the JSP page is served.

The JSP <%@include@%> directive is commonly used to modularize web pages, to reuse content, and to keep web page size manageable. Using a JSP <%@include@%> directive results in a larger servlet and, if abused, could lead to code bloat. Page headers and footers are common examples of when an include directive might be used.

The <jsp:include> action is commonly used to insert dynamically-generated content into a JSP page at the time it is served, or to select among alternatives in content for inclusion at runtime. A <jsp:include> action is more flexible than an <%@include@%> directive, since it can select the content to include at runtime. But a <jsp:include> action requires runtime processing and is therefore slower than an <%@include@%> directive.

Each time a particular JSP page is requested, all of its included pages are evaluated (and recompiled if necessary). The child page must redeclare the components it uses (for example, JavaBeans and objects provided by the container). Input data is shared between pages by way of the HttpSession object.

The Java Pet Store uses primarily <jsp:include> actions, because most of its JSP pages produce dynamic content.

One important, subtle difference between the <%@include@%> directive and the <jsp:include> action: the <%@include@%> directive is problematic for internationalization, because the contentType:charset of the included page cannot be set indepdendently of the including page. If you need control of the page encoding, the <jsp:include> action is your only choice in JSP 1.1.

Implementation note: Some implementations of the web container (including Tomcat) do not automatically track modifications to files included by an <%@include@%> directive. If you change a file that is included, you also need to force a recompile by "touching" (change the modification date of) the "parent" files that include the modified file.

See also:

Session state in the web tier

CONTENTS | PREV | NEXT | INDEX