Core JSP by Damon Hougland and Aaron Tavistock - Part6

Couple of Days back i started reading Core JSP by Damon Hougland and Aaron Tavistock.

Nice book written by Damon Hougland and Aaron Tavistock.

Few important quotations i wanted to share from next two chapters (11-12).

1) Custom Tag Basics

Tag libraries are extremely powerful, and thus fairly complex. They incorporate all of the tag features of JSP actions, such as supporting nested actions, scripting elements,and the creation of scripting variables. They can be used to instantiate objects, and are scripting-language neutral. Probably their most powerful feature is that the JSP author can develop a component and never need to understand the inner workings of the tag library, or even the calling methods.

2) Tag libraries are tied to the taglib directive by the uri attribute of the taglib directive. It can be any valid URI as long as can be used to identify the semantics of the tag library.

At the heart of the tag library is the tag handler. The tag handler is a server-side object that is created to evaluate actions during the execution of a JSP page. Every tag library extends one of the tag handler classes. It supports a protocol that handles the passing of information between the JSP page and the custom tag.

The taglib directive is the mechanism that ties the tag library descriptor to the JSP page, as well as set the tag namespace prefix to be used in the JSP page. It has two attributes, both of which are required.

The uri attribute contains a Universal Resource Identifier (URI) that points to the location of the Tag library. In the case of a jar file distribution of a tag library, the URI points to the jar file itself, which contains the tag library descriptor in the form of a taglib.tld file.

The prefix attribute identifies the XML namespace prefix that will identify tags that are a part of the new tag library. The namespaces available to a JSP page is limited to the default jsp namespace as well as any namespace created by the taglib directive.An example taglib directive might look like:

<%@ taglib uri="http://www.javadesktop.com/taglib/htmltool.jar" prefix="tool" %>

3) The Tag Library Descriptor

The tag library descriptor (TLD) is an XML document that describes a tag library. It is used by the JSP container to interpret pages that contain taglib directives. It can also be used by JSP authoring tools that generate JSP pages using tag libraries.

The TLD is basically a set of metadata about a tag library. It describes the tag library as a whole, as well as describing its individual tags, attributes, version numbers, and other information. Each action in the tag library is listed in the TLD. Information contained for each action includes its name, the class that contains its tag handler, and all of its attributes.

The distinct advantage of having a TLD file is that tools can find out information about a tag library without having to instantiate objects or load libraries. This is a standard approach that is used in many parts of the Java 2 Enterprise Edition (J2EE).

4) Understanding the Tag Library Descriptor File

The tag library descriptor (TLD) file is used to describe everything about a tag library.Everything the JSP page knows about the tag is acquired from this file.

In fact, the JSP engine actually builds the method signatures that are available by reading this file. Minor errors in this file can cause some interesting errors that a state that the constructors signature does not match the method call.The TLD file follows an XML style of syntax, so it includes nested structures.

Fortunately, its a fairly simple file and is relatively easy to break down into logical blocks.

5) The doStartTag() method will be run when the tag is first called. It checks if there are iterations to do. If there are no iterations to do then the SKIP_BODY constant is returned, which says essentially "ignore everything between the start and end tags." If there are iterations to be done, the EVAL_BODY_TAG is returned that says "process everything between the start and end tags."

Each time the body is processed doAfterBody() method is called. This method first increments the iteration counter.Next, it does the same thing the doStartTag() method did, if there is more iteration, process the body. Since this method is called after each body is processed, it creates the loop.

Next the doEndTag() occurs, this is called when the closing the tags. This tag contains a particularly interesting looking piece of code:

6) Reducing Complexity with Decomposition

The most effective way of designing an application architecture is by decomposing an application into separate components. This is the underlying theme in all modern forms of design and is the foundation of object-oriented development. Component based architectures are built on the concept of modules, which can be developed,changed, or upgraded independently of the entire application. This builds a high level of abstraction, and allows applications to be developed in team environments. It also produces code that is more maintainable then applications with a centralized design.However, application architects should be wary of the amount of granularity used with component-based design. While decomposing an application into separate components has many benefits, separating components into too granular of a framework can actually make an application more complex. The key is to have a sound organization to the separation of components, and to size the level of component granularity with the size of both the application and the development team.

7) Tag libraries can also be extremely useful with visual development environments. It's likely that many standard HTML editors will support the use of custom tags in the near future. Because they are portable in nature and use XML as a configuration language they are perfect for integrating into IDEs.

Tag libraries are an excellent way to separate Java code from the presentation layer.They are the perfect solution for creating templates or for including control-flow operations into JSP pages in a component-based, reusable manner.

Tag libraries, just like JavaBeans and include actions, have their own advantages and disadvantages. Taken together these three methods allow many different types of decomposing JSP pages into reusable components.

8) Presentation Logic

Presentation logic is the part of the application that deals with the presentation layer.It deals with the user interface and Web-based elements, such as HTML and XML.Presentation logic is concerned with displaying the information, not how the information was retrieved or how the application chose to display this information.

Presentation logic components can also contain logic about the direction the application will flow based on user input. When this happens there is no controller component. In other words, it handles not just displaying information to the user, but receiving information as well. In the case of JSP pages this means handling both the HTTP request as well as the response. When presentation logic contains logic to process the HTTP request, there is no separation of presentation logic from controller logic.

9) Controller Logic

Controller logic may or may not be present in the presentation logic, and this is the delineation between the different levels of JSP application component separation. Controller logic "controls" the application flow, and serves as the connector between the user interface and the application.

In the JSP application controller logic receives and interprets the HTTP request,deciding the next step of the application based on user input. When there is a separation of controller logic, the presentation layer simply concerns itself with the HTTP response.

A key function of the controller layer is the management of connections to the application layer. In the case of JavaBeans this means instantiating and connecting to the JavaBeans, as well as passing the results to the presentation layer.

10) Application Logic

Application logic is the center of the application. The application logic is responsible for the logic behind what the application is supposed to accomplish. For example, in a Web-based registration system the application logic would consist of taking the submitted name, checking it against the database, adding it to the database, and returning a result.

It is important to point out that there is no user interface logic in the application layer.This means that the application logic components can reside completely outside of the JSP application; in an Enterprise JavaBean or a CORBA API, for example.

One of the great benefits of a separate application logic layer is the ability to have multiple user interfaces to the same application. A Swing Java stand-alone application can connect to the same JavaBeans that a JSP application connects to and perform the same functionality through a different GUI.

11) JSP Model 1 is seen as a reasonable solution for fairly simple applications. Issues arise when the logic contained within the JSP page grows. With a large amount of logic there tends to be a lot of scriptlets or Java code within the JSP page. This is often the case with large applications. As a Java developer this may not seem a problem, but when designers maintain the JSP page an issue can arise from having
large amounts of Java code on a JSP page.

In essence, the problem is that having two roles—application logic and presentation logic—is no longer sufficient to have a good separation of code. As more and more logic surrounds processing the HTTP request there is a greater need for separate "controller" logic to guide the flow of data and logic within the application. This idea gives birth to the JSP Model 2.

12) Model 2: Separating Controller and Presentation Logic

JSP Model 2 adds a Java Servlet to the architecture to fulfill the role of processing the HTTP request and controlling data and logic flow. It decides what JSP page to forward to based on the request. It also is responsible for instantiating or connecting to any JavaBeans for application logic.

This model takes advantage of the strengths of both Servlets and JSP pages. Servlets are especially strong in processing-intensive tasks, and JSP pages are excellent for presenting data.

The three roles that make up the JSP Model 2 often mimic the roles of enterprise development projects. There is often a team for a core programming API represented by the JavaBeans or Enterprise JavaBeans. Another team might represent creating a Web-based front end for the API, much as another team might develop a Java Swingbased front end. This is represented by the Servlet or controller logic. Finally the JSP
pages represent the designers or creative team of the development project. All in all,the Model 2 design pattern adds a new layer of abstraction to the JSP application development process, helping to scale the development of large, enterprise applications.

About the Authors

DAMON HOUGLAND is a Program Manager and Technical Architect for eFORCE, Inc., where he designs and develops Java enterprise applications. Previously Damon led the Web Application Infrastructure team at Lawrence Berkeley National Laboratory, which specialized in reporting scientific data through web-enabled databases and applications. He has worked as a software developer and technical manager over the last nine years.

AARON TAVISTOCK has over 10 years of experience with UNIX systems and application development. He has used his extensive knowledge of Java, JSP, and taglibs to create a leading edge web application compiler. Aaron is currently the Web Compiler Architect for Snapshop.com, Inc., a provider of B2B2C (business-to-business-to-consumer) web applications.