Questions and Answers - Web Tier



Guidelines, Patterns, and code for end-to-end Java applications.

Questions and Answers - Web Tier
  2. What kind of code should pages created with JavaServer Pages technology (JSP pages) contain ?
  4. When should I use JSP-style comments instead of HTML-style comments?
  6. How can servlets be made more easily distributable?
  8. My JSP page does not reload when I change it. What's going on?
  10. Can JSP pages process forms?
  12. How do I use international character sets?
  14. 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 technology (JSP pages) contain ?



link | link


  • 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.



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.



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 as
escape sequences
\u5fa1 \u6ce8 \u6587 \u3042 \u308a \u304c \u3068 \u3046 \u3054 \u3056 \u3044 \u307e \u3059 \u3002
Unicode as
numeric character
&#5fa1;&#6ce8;&#6587;&#3042;&#308a; &#304c;&#3068;&#3046;&#3054;&#3056; &#3044;&#307e;&#3059;&#3002;




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.














Implementation note<%@include@%>

See also:

Session state in the web tier
Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve
Java 8 banner (182)