Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
7Activity
0 of .
Results for:
No results containing your search query
P. 1
JSP Best Practices

JSP Best Practices

Ratings: (0)|Views: 1,756|Likes:
Published by nadeesh86
Best Jsp Practices
Best Jsp Practices

More info:

Published by: nadeesh86 on Aug 22, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/13/2010

pdf

text

original

 
JSP best practices
Follow these tips for reusable and easily maintainableJavaServer Pages
Summary
 This article discusses simple approaches and best practices that, whenused correctly, facilitate JavaServer Pages (JSPs) development. Thesetips ensure reusable and easily maintainable JSPs, JSPs that allowdevelopers to focus on their programming strengths. (
3,000 words;
 
November 30, 2001
)
By Dustin Marx
avaServer Pages (JSPs) technology is an extension of Java servlet technology andcombines HTML and Java code into a single file. While Java servlet technologyfocuses on Java classes capable of generating HTML output with
PrintWriter.println()
 statements, JSP technology abstracts this concept to a higher level. With JavaServerPages, a Web developer can write static HTML pages and simply add Java code inthose sections of the page that need to be dynamically generated. While thisflexibility enables rapid development of simple Web applications, it can be abused,resulting in unnecessarily complex applications that are difficult to maintain, reuse,and enhance.To avoid needlessly complex applications, follow the practices I present in thisarticle:1. Separate HTML from Java2. Place business logic in JavaBeans3. Factor general behavior out of custom tag handler classes4. Favor HTML in Java handler classes over Java in JSPs5. Use an appropriate inclusion mechanism6. Use a JSP template mechanism7. Use stylesheets8. Use the MVC pattern9. Use available custom tag libraries10. Determine the appropriate level of XML compliance11. Use JSP comments in most cases12. Follow HTML best practices13. Utilize the JSP exception mechanismThese tips will help you write JSPs that are reusable and easy to maintain.
Separate HTML from Java
It can be tempting to throw all Java and HTML code necessary for a Webpage into asingle JSP file. In simple system development, such an approach makes it easy forsomeone new to the system to locate all relevant code in one place and understand
 
how it all interacts. However, this approach becomes burdensome and costly whenthe application grows more complex and more developers become involved.Combining HTML and Java in the same source code can make the code significantlyless readable. To enhance software readability, developers often use indentation; butmixing HTML and Java scriptlets in the same file can make useful indentationextremely difficult to maintain.Many Web development methodologies and architectures now emphasize theseparation of HTML from Java code so different developers can focus on theirstrengths. Properly separating Java and HTML, including HTML-like JSP tags andcustom tags, allows Web designers and HTML coders to work on the HTML(presentation) aspects, while Java developers work on the application's Java(processing logic) portions. Java developers focus on business logic as theyimplement the behavior behind the custom tags; Web designers then use thesecustom tags just as they use ordinary HTML tags.Applications with Java properly separated from HTML are more reusable because theJava components are not tied to a Web browser and can be used by other parts of the application. In addition, maintainability is enhanced because of the increasedmodularization that comes from Java/HTML separation.Placing business logic in JavaBeans also promotes stronger applications. I'll explainhow next.
Place business logic in JavaBeans
Java code included directly inside a JSP is not as readily accessible to other JSPs asJava code contained within a JavaBean. Common behavior and business logic placedin JavaBeans can not only be used by other JSPs but also by other portions of theapplication. That is because JavaBeans are merely Java classes that satisfy somebasic conventions (such as a constructor with no arguments and public
get
 /
set
 methods for private data members) and can be used as any other Java class. Notethat Enterprise JavaBeans (EJBs) are also useful for storing behaviors and datacommon to all components of the application.
Factor general behavior out of custom tag handler classes
Java classes known as
custom tag handlers
implement custom tags. UnlikeJavaBeans, custom tag handler classes are not readily used like ordinary Java utilityclasses. Instead, custom tag handler classes implement specific interfaces -- orextend classes that provide these interfaces' basic implementations. Because theyare not readily reused outside JSPs, custom tag handlers should contain only specificbehavior 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 canutilize 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 Javarequires unnecessarily convoluted code. In these cases, you either include Javascriptlets and expressions in the JSP or put some HTML code in the Java tag handlerclass. 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 specificto 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 documentationdiscusses this issue further.There are exceptions to this standard: if including one or two lines of Java code asscriptlets 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 beprudent.
Use an appropriate inclusion mechanism
It is rarely good design to reproduce code commonly used by different applicationpieces each time another piece of that application needs that functionality. Factoringcommon JSP or HTML code out of multiple pages and into a single file improvesmaintainability (you need to make changes in only one location) and reusability.Two JSP
include
mechanisms reduce code redundancy and promote reusability; toensure that you use the appropriate include mechanism, it is important to know thedifferences 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" sectionprovides a good resource for understanding the differences between the two includemechanisms 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 theinclude mechanism for situations when text, such as ASCII or HTML, needs to beincluded in multiple JSPs. For example, I commonly use the include directive toinclude footer information, such as company name or copyright date, on every JSP ina company's application.Since you include the content of any file specified by the include directive in thecalling JSP before it compiles, variables and other values specified in the calling JSPcan also be utilized in the included content. However, I try not to rely on variablesdefined in the calling JSP, since this dependency reduces the included file'sreusability.
Include action
The include action executes the specified JSP first and then places the generatedresponse in the calling JSP. Because the include action includes the generatedresponse rather than the source content itself, variables and other values specified inthe calling JSP are not available to the page included with the include action.One disadvantage of the include action as currently implemented by the JSPimplementations with which I am familiar relates to the
flush="true"
attribute. In theJSP 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 pagespecified by the include action executes. This can prove problematic if the forwardmechanism is invoked either explicitly or implicitly later in the JSP. In the recentlyreleased JSP specification (1.2), however, the include action's
flush
attribute can beset to
false
. Tomcat 4.0 provides a reference implementation of this specification andsupports this new include action argument.
Use a JSP template mechanism

Activity (7)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
joseph_ds5240 liked this
meetdevarshi4519 liked this
cr@zyyyyy liked this
sapna24 liked this
sagar_sea liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->