 | |
|
Guidelines, Patterns, and code for end-to-end Java applications.Questions and Answers - Web Tier
1. What kind of code should pages created with JavaServer Pages technology (JSP 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:
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
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.
native2ascii
that translates non-ASCII encodings to ASCII escape sequences.
7. When should I use a JSP
A JSP <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.
| ||||||||||||||||||||
| |
| ||||||||||||
Print-friendly Version
