JSP Design Notes
White paper sections
Introduction The Technology Prevalent Application THE Alternative Conclusion
Introduction to JSP Design Notes
Java Server Pages (JSP's) permit server side Java logic to reside within the requested document. Upon request of a JSP document the server activates the specified JSP. The JSP then becomes responsible for providing an HTML response.
The server side logic within a JSP is written in Java. The Java code segments, referred to as scriptlets, are generally responsible for providing dynamic HTML content to the JSP's response HTML. The JSP itself is compiled by the server, and is executed as an Object That Extends The Java Servlet API. AS Such, The Http Servlet Request and Response Objects Are Available By The ScriptleTs Defined Wtem, The JSP.
This document reviews client-server design considerations in respect to the use of JSP Zha. Implementation options, particularly the use of JSP language extensions and use of Enterprise Java Beans (EJB's) will also be discussed. Focus will be placed on the presentation layer and HOW THE JSP IS Used to Provide a User Interface and Communicate Business Logic Requests To The Supporting System.
If we consider a 3-tier architectural WEB application, the browser becomes the client side application. The user communicates requests to the WEB / app server via the browser. The presentation layer receives the client requests and prepares the response and server side business functionality is executed. In the context of this example, the JSP engine represents the presentation layer. It is responsible for processing requests and responses. Additional messages may be passed between this layer and that which handles business processes represented below as EJB Zha .Return to Top of Page
THE TECHNOLOGY
JSP technology uses XML -. Like tags and scriptlets They are used to encapsulate presentation logic within the JSP They can also initiate messages to distributed or server-side applications The logical separation of presentation and business logic lies in the implementation of the JSP...
Enterprise Java Beans Provide a Distinctation of Business Logic and The Remote Interfaces Provided to The EJB Client. The Use of an EJB TYPICLY FOLLOWS The Pattern:
The client application identifies itself to the server The client application uses the Java Naming Directory service to locate the desired EJB The client application retrieves a handle to the EJB Home and subsequently Remote interfaces.
The remote interface contains methods that the client is permitted to use. They represent a summary of the business logic that is implemented by the bean. The implementation logic is defined within the primary bean class. All IPC, database and resource details are restricted to the Bean class.
Return to Top of Page
Prevalent Application
Design constraints and conventions maintain the separation of presentation logic from business logic in the middle tier Prior to JSP 1.1, a JSP implementation using EJB's might have included various scriptlet sections performing EJB remote interface logic / communication.Consider the example below.:
The JSP Is Designed to Provide a Welcome Message To AN E-Commerce User. Assume The Request Included An HTML Name-Value Pair That Identified The (Pre-Registered) Customer ID.
The resulting JSP is a hybrid of scripting logic and html. In constructing a JSP document, the creation of the HTML base is a prudent step. It becomes the visual template that JSP scriptlets are merged into. The post execution HTML produced from the completed JSP should be that of the original HTML document. With the exception of comment, dynamically generated HTML sections and JSP content substitutions. The scripting logic, except for where desired, is completely non visual in regard to the response HTML text.
The construction of the HTML layout conceivably begins with a Web developer. The creation of the JSP pages would be similar if not identical to the methods used to construct industry HTML pages. The next step would be the addition of JSP specific logic to identify the sections of the HTML that might be generated dynamically. This conversion step from pure HTML to JSP is where server side logic is added to the page.A completed JSP logically embodies presentation layer services and business functionality. Physically they are blended within the JSP in an as needed swapping of HTML and JSP code. Continued maintenance of the application and changes in the business logic need not affect the presentation layout. Likewise, changes in the presentation layout need not affect the scriptlet logic, it will however require that the WEB developer, not NECESSARILY A Java Programmer
Return to Top of Page
The alternative
A design consideration intended to reduce the complexity of maintaining the HTML aspect of a JSP is to minimize the use of scriptlets in constructing a JSP. Custom tags, introduced in JSP 1.1, can equally produce the functionality provided by JSP scriptlets.
Custom Tags Are Application Defined Language Extensions To Java Server Pages. Custom Tags Can Be Used WITHIN A JSP in The Following Ways:
to produce html output to produce JSP output (JSP expressions, directives, ...) to create objects to define objects that can be seen as scripting variables within the parent JSP to iterate over a body of JSP / HTML text in a finite manner to DETERMINE IF Section of The Calling JSP Should Be Processed Or Skipped
The goal of using custom tags to minimize the presence of scriptlets is to produce a more HTML? Like JSP. The advantages of this goal are self-evident if we consider projects that expect frequent HTML modifications. Assuming the business logic, pre-presented by the JSP tags, is stable it can be identically merged into various forms of the HTML layout, without explicitly inserting duplicate sections of scriptlet logic (Java code) .Tag handlers implement JSP custom tags. One or more tag handlers can be listed in the Tag Library Descriptor files. References to these files are included in the JSP that intends to use a given tag handler. The tag handler itself is implemented as a Java object that extends the JSP body. Upon execution it has access capabilities to the JSP's Http servlet objects IT CAN, CONCEIVABLY, PROVIDE A FULL HTML RESPONSE TO The Client in The Way That Servlets Operate. A Significant Distinction from Java Server Pages Is That Tag Handlers Are Not Designed To Be Dynamically Compiled by the Server.
In respect to EJB's, a tag handler accesses an EJB in the same manner as the above scriptlet. It can additionally make available any object it creates, available to other tag handlers and JSP Zha. This is accomplished by the use of storage methods that operate .......... ...
The Previous JSP Example Implement Using Custom Tags Might Appear As Follows:
<% taglib declaration; prefix = tagpre%>
Figure 2 gives a graphical representation of the physical control flow without the use of custom tags. The client initiates execution with a JSP request. The request via URL is directed to the WEB server that is responsible for servicing such requests. The JSP request triggers the .
Logically Identical, Figure 3 illustrate the use of tag handlers by the jsp. This is the hidden logic Implied in HTML EXAMPLE 2.
The JSP engine, in both figures, treats the compiled JSP object as a servlet object. Figure 3 Zha tag handler object extends the JSP page body. This relationship grants tag handler access to various servlet attributes. These attributes therefore permit the tag handler to conceivably Inspect parameters passed by the client.
Return to Top of Page
Conclusion
As with other tools of the trade, innovations and nuances to existing tools do not invalidate existing design methodologies. They do however provide new versatility and the expansion of possibilities with regard to application design.Custom tag extensions, in contrast to standard tags, provide the application builder the ability to define custom tags to satisfy some functionality not provided by the standard API. to benefit by using tag extensions to reduce the amount of Java functionality that the JSP API provides, might seem oxymorinic, and it is. With the exception of .
While a server side application designer does not typically consider the cosmetic aspect of implementing source code, JSP source code might prove to be the exception. It does after all suggest the strong possibility that a Web / HTML developer perform the continued maintenance of the HTML portion Of the JSP. this is a role, of course, traditional allied with client side responsibilities.
The nuances introduced by JSP custom tags present nuances in the maintenance of JSP Zha. The arguments presented here presume that the HTML produced by the JSP Zha in discussion are non-trivial HTML documents, although non-complex HTML documents may benefit from similar design considerations .
~ End of Aurora Information Systems' White Paper Series # 9 "JSP Design Notes" ~