【正文】 interfaces180。 basic implementations. Because they are not readily reused outside JSP, 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 mon behaviors or business logic and can utilize JavaBeans or EJB that perform those mon behaviors. Favor HTML in Java handler classes over Java in JSP Sometimes cleanly separating HTML, JSP tags, and HTMLlike custom tags from Java require unnecessarily convoluted code. In these cases, you either include Java script lets 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 script lets and expressions, in the JSP. Since custom tag handlers are specific to the custom tags they implement (and not reusable outside JSP), 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 script lets 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 monly used by different application pieces each time another piece of that application needs that functionality. Factoring mon 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 Blueprints180。 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 An Asp’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 JSP. For example, I monly use the include directive to include footer information, such as pany name or copyright date, on every JSP in a pany’s application. Since you include the content of any file specified by the include directive in the calling JSP before it piles, 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. Include action The include action executes the specified JSP first and then places the generated response in the calling JSP. Because the include action includes the generated response rather than the source content itself, variables and other values specified in the calling JSP are not available to the page included with the include action. One disadvantage of the include action as currently implemented by the JSP implementations with which I am familiar relates to the flush=true attribute. In the JSP implementations I have used, this attribute is required and must be set to true. The true value indicates that the buffer will always flush before a target page specified by the include action executes. This can prove problematic if the forward mechanism is invoked either explicitly or implicitly later in the JSP. In the recently released JSP specification (), however, the include action’s flush attribute can be set to false. Tomcat provides a reference implementation of this specification and supports this new include action argument. Use a JSP template mechanism A template mechanism allows for a mon file to control Webpage, or JSP, layout. Then, when you want to change the layout, you need to modify only one file, and all the other pages will reflect the layout change. This doesn’t just make for more maintainable code。 using templates to control layout also makes WebPages more aesthetically pleasing to users who see consistent layouts for all an application’s pages. I use Struts180。 custom tag template library as a template mechanism. David Geary’s article JSP Templates provides a good starting point for looking at using templates with your JSP. Use style sheets Just as templates enable developers to place layout control in a single location, style sheets enable developers to place appearance control in a single location. I use Cascading Style Sheets (CSS) to control such items as font families, font sizes, and table characteristics. Like templates, style sheets allow the developer to make changes in one location。 those changes immediately reflect on all appropriate pages, resulting in increased maintainability and consistent appearance to users. Use the MVC pattern While other design patterns can be used effectively with JSP, I often use the ModelViewController (MVC) architecture with JSP technology. MVC enables the development of applications that are easier to create, test, maintain, and enhance. In JSP terminology, implementation of an MVC architecture is often referred to as Model 2 (from an early JSP specification). The J2EE Blueprints samples are based on MVC. See E++: A Pattern Language for J2EE Applications, Part 1 by Bin Yang, and Understanding Java Server Pages Model 2 Architecture by Gavin Seashore, for more information on JSP and MVC. Struts Struts is an open source MVC implementation (it’s a Jakarta subproject available through the Apache license) that provides base controller functionality that you can extend and enhance in your own applications. The base controller is implemented as a Java SERVLET, and its co