Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

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

JavaWorld.com > Java Enterprise Edition >

JSP best practices

Follow these tips for reusable and easily maintainable JavaServer Pages

By Dustin Marx, JavaWorld.com, 11/29/01

  • Print
  • Feedback
.

Page 2 of 6

Factor general behavior out of custom tag handler classes

Java classes known as custom tag handlers implement custom tags. Unlike JavaBeans, custom tag handler classes are not readily used like ordinary Java utility classes. Instead, custom tag handler classes implement specific interfaces -- or extend classes that provide these interfaces' basic implementations. Because they are not readily reused outside JSPs, custom tag handlers should contain only specific behavior that would not be useful outside that custom tag -- that is, outside the JSP. Custom tags often require support for common behaviors or business logic and can utilize JavaBeans or EJBs that perform those common behaviors.

Favor HTML in Java handler classes over Java in JSPs

Sometimes cleanly separating HTML, JSP tags, and HTML-like custom tags from Java requires unnecessarily convoluted code. In these cases, you either include Java scriptlets and expressions in the JSP or put some HTML code in the Java tag handler class. I'd rather see a small amount of HTML code in the Java class than see Java, such as scriptlets and expressions, in the JSP. Since custom tag handlers are specific to the custom tags they implement (and not reusable outside JSPs), placing necessary HTML there is not troublesome. Sun's Java 2 Platform, Enterprise Edition (J2EE) Blueprints documentation discusses this issue further.

There are exceptions to this standard: if including one or two lines of Java code as scriptlets in the JSP solves the same problem that would require many more lines of HTML in the Java handler class, allowing Java code to exist in the JSP page might be prudent.

Use an appropriate inclusion mechanism

It is rarely good design to reproduce code commonly used by different application pieces each time another piece of that application needs that functionality. Factoring common JSP or HTML code out of multiple pages and into a single file improves maintainability (you need to make changes in only one location) and reusability.

Two JSP include mechanisms reduce code redundancy and promote reusability; to ensure that you use the appropriate include mechanism, it is important to know the differences between the two. Generally, I use the include directive unless I can justify a need for the include action. Question 7 in the Blueprints' "Web Tier" section provides a good resource for understanding the differences between the two include mechanisms and determining which to use in a particular situation.

Include directive

A JSP's include directive includes the content of a specified file in that JSP. Use the include mechanism for situations when text, such as ASCII or HTML, needs to be included in multiple JSPs. For example, I commonly use the include directive to include footer information, such as company name or copyright date, on every JSP in a company's application.

Since you include the content of any file specified by the include directive in the calling JSP before it compiles, variables and other values specified in the calling JSP can also be utilized in the included content. However, I try not to rely on variables defined in the calling JSP, since this dependency reduces the included file's reusability.

  • Print
  • Feedback

Resources