j2ee: Advanced JSP

Contents [0/27]

Overview of Today's Class [1/27]
Java Code in JSPs - different mechanisms [2/27]
JSP Expression Language - concepts [3/27]
JSP Expression Language - capabilities [4/27]
JSP Expression Language - setup [5/27]
JSP Expression Language - accessing variables [6/27]
JSP Tag Extensions [7/27]
Creating Tags [8/27]
Implementing a Tag Handler [9/27]
The SimpleTag Interface [10/27]
The Tag Interface [11/27]
The IterationTag Interface [12/27]
The BodyTag Interface [13/27]
The TryCatchFinally Interface [14/27]
The Tag Library Descriptor [15/27]
Deploying Tag Libraries [16/27]
Using Tag Libraries [17/27]
Tag Files [18/27]
JSTL [19/27]
JSTL tags [20/27]
Struts overview [21/27]
Struts Model Components [22/27]
Struts View Components [23/27]
Struts Controller Components [24/27]
Struts configuration example [25/27]
JavaServer Faces overview [26/27]
Assignment [27/27]

Overview of Today's Class [1/27]

Newer and Advanced JSP concepts

Assignment

Java Code in JSPs - different mechanisms [2/27]

Let's review the mechanisms we have seen so far to run Java code in a JSP.

  1. Scriptlets - call Java code directly
  2. Scriptlets - call Java code indirectly (use of utility classes)
  3. Beans - utility classes as Beans, use the jsp:useBean, jsp:getProperty, jsp:setProperty actions to call the Bean code
  4. MVC - use the MVC architecture with JavaBeans

These are listed in order of complexity or application development team size. By employing more of these techniques, we can separate the project into the areas of expertise needed to complete the coding.

The next two techniques we'll look at are the JSP expression language, and custom tag libraries

  1. JSP Expression Language - using a shorthand syntax for accessing objects and their properties
  2. Custom Tag libraries - using tag handler classes as specialized code to handle specific display functionality

JSP Expression Language - concepts [3/27]

The JSP expression language was initially described in the Java Standard Tag Library. This is just a set of Custom Tag Libraries meant to standardize the most common functions needed in JSPs. The language is independent of JSP except for the set of implicit objects it defines, and can be reused elsewhere. The JSTL version 1.0 can be used in a JSP 1.2 container. In JSP 2.0, some changes were made to the language, and JSTL 1.1 incorporates those changes. JSP 2.0 is required for the JSP EL to be available outside of the JSTL tags.

The EL is based on:

JSP EL is inspired by ECMAScript (a.k.a JavaScript) and XPath (XML)

JSP EL is meant to replace Java Code in JSPs, and with 2.0 it is available in attribute values and template text using the construct ${expr}

JSP Expression Language - capabilities [4/27]

The JSP EL has the following capabilities:

JSP Expression Language - setup [5/27]

In a JSP 2.0 container, you have some control over the EL.

To turn it off:

You can also turn off scriptlets for a set of JSPs using the jsp-property-group element of web.xml

Examples:

disabling EL:

        <jsp-property-group>
            <url-pattern>*.jsp</url-pattern>
            <el-ignored>true</el-ignored>
        </jsp-property-group>

disabling scripting:

        <jsp-property-group>
            <url-pattern>*.jsp</url-pattern>
            <scripting-invalid>true</scripting-invalid>
        </jsp-property-group>

JSP Expression Language - accessing variables [6/27]

To access a scoped variable, just use the variable name in the EL syntax: ${name}

The following would be equivalent:

        <%= pageContext.findAttribute("name") %>

or

        <jsp:useBean id="name" type="package.className" scope="..."/>

You need to makes the variable names are valid Java syntax for names. It is possible to store the name under any string, so make sure these names are valid as variable names

JSP Tag Extensions [7/27]

Allows introduction of new actions into a JSP

A collection of actions that encapsulate some functionality to be used in JSPs.

A Tag Library can be used to define a specialized sub language of JSP that allows the users of that library to use it naturally with JSPs.

Goals of Tag Libraries

The JSP Process - when a JSP is processed, it follows these steps:

Creating Tags [8/27]

A custom tag consists of a tag handler and a tag library descriptor

Types:

To use the tag:

A custom tag must implement the javax.servlet.jsp.tagext.Tag or javax.servlet.jsp.tagext.SimpleTag interface (which now extends javax.servlet.jsp.tagext.JspTag for organizational purposes

This is usually done by extending a base utility class

The Tag interface supplies doStartTag() and doEndTag()

BodyTag supplies doInitBody(), setBodyContent()

IterationTag supplies doAfterBody()

TryCatchFinally supplies doCatch(), doFinally() and helps tags manage resources better

Implementing a Tag Handler [9/27]

To implement a tag handler:

The SimpleTag Interface [10/27]

doTag() - Called by the container to invoke this tag, and is called once and only once. The lifecycle for SimpleTag is simpler than Tag, IterationTag, or BodyTag.

Lifecycle:

  1. A new tag handler instance is created each time by the container by calling the provided zero-args constructor. Unlike classic tag handlers, simple tag handlers are never cached and reused by the JSP container. This can be a performance issue, but in modern JVMs is not nearly as much of an issue.
  2. The setJspContext() and setParent() methods are called by the container. The setParent() method is only called if the element is nested within another tag invocation.
  3. The setters for each attribute defined for this tag are called by the container. Use JavaBean conventions for this functionality.
  4. If a body exists, the setJspBody() method is called by the container to set the body of this tag, as a JspFragment. If the action element is empty in the page, this method is not called at all.
  5. The doTag() method is called by the container. All tag logic, iteration, body evaluations, etc. occur in this method.
  6. The doTag() method returns and all variables are synchronized.

If you need to create a SimpleTag, but use it as a classic tag, you can use a TagApapter to wrap the SimpleTag and then the SimpleTag can be used where a classic Tag is expected.

The Tag Interface [11/27]

doStartTag()

doEndTag()

Lifecycle:

Tag Protocol

The IterationTag Interface [12/27]

doAfterBody()

Lifecycle:

Iteration Tag Protocol

The BodyTag Interface [13/27]

Lifecycle:

Body Tag Protocol

The TryCatchFinally Interface [14/27]

An auxiliary interface for tags that want more control over resources

doCatch()

doFinally - invoked in all cases after doEndTag() for any class implementing Tag, IterationTag, or BodyTag

The Tag Library Descriptor [15/27]

In order for your tag library to be processed properly by the Servlet container, you must supply a configuration file known as a tag library descriptor. This basically servers the purpose of web.xml for a web application, it is information that the container uses to manage the libraries at runtime

http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd for JSP 2.0

http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd for JSP 1.2

http://java.sun.com/dtd/web-jsptaglibrary_1_1.dtd for JSP 1.1>

TLD structure:

Examples:

<?xml version="1.0" encoding="UTF-8" ?>

<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
	http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
	version="2.0">


    <tlib-version>2.0</tlib-version>
    <jsp-version>2.0</jsp-version>
    <short-name>se452</short-name>
    <uri>/se452</uri>
    <display-name>se452-taglib</display-name>
    <small-icon></small-icon>
    <large-icon></large-icon>
    <description>
        A set of example tag libraries for SE452 at DePaul University
    </description>
    
    <tag>
        <name>date</name>
        <tag-class>se452.tags.DateTag</tag-class>
        <body-content>empty</body-content>
        <description>
        Prints the current time and date
        </description>
    </tag>
  
    <tag>
        <name>debug</name>
        <tag-class>se452.tags.DebugTag</tag-class>
        <body-content>JSP</body-content>
        <description>
        Includes the contents of the tag if debug request parameter
        is set to true
        </description>
    </tag>
    
    <tag>
        <name>select</name>
        <tag-class>se452.tags.SelectTag</tag-class>
        <body-content>empty</body-content>
        <description>
            Displays an html select with preselected options
        </description>
        <attribute>
            <name>name</name>
            <required>true</required>
            <rtexprvalue>true</rtexprvalue>
            <type>java.lang.String</type>
        </attribute>
        <attribute>
            <name>selected</name>
            <required>false</required>
            <rtexprvalue>true</rtexprvalue>
            <type>java.lang.String</type>
        </attribute>
        <attribute>
            <name>list</name>
            <required>true</required>
            <rtexprvalue>true</rtexprvalue>
            <type>java.lang.String</type>
        </attribute>
    </tag>
    
</taglib>

Deploying Tag Libraries [16/27]

  1. Put the class files in "doc root"/WEB-INF/classes
  2. Put the tag library descriptor anywhere in the webapp
  3. Edit WEB-INF/web.xml, Add the following to your web.xml after servlet-mappings and session-config, but before resource-ref:

<jsp-config>
    <taglib>
        <taglib-uri>se452-taglib.tld</taglib-uri>
        <taglib-location>/WEB-INF/tld/se452-taglib.tld</taglib-location>
    </taglib>
</jsp-config>

Using Tag Libraries [17/27]

Use taglib directive


<%@ taglib uri="se452-taglib.tld" prefix="se452" %>

Write the tag in the JSP

<se452:tag1>

or

<se452:tag1>
	Body (any JSP/html/Text)
</se452:tag1>

Tag Files [18/27]

JSP Tag files are a new addition to the JSP 2.0 specification. They allow JSP authors to create tag extensions that are made only of JSP syntax , instead of Java syntax.

The syntax of a tag file is similar to that of a JSP page, with the following exceptions:

The basic goal it so make it as easy to write a tag file as it is to write a JSP.

Tag files are deployed in the META-INF/tags directory of a jar file in WEB-INF/lib of a war file, or they are placed in the WEB-INF/tags directory of the web application. If the former is chosen, the tag library descriptor (.tld) file needs to point out the details on the tag. If placed in the WEB-INF/tags directory, the tag files can be discovered by the container, and the container creates the tld. For example, with a tag file /WEB-INF/tags/depaul/j2ee/demo.tag, the following tld would be created:


				
				<taglib> 
					<tlib-version>1.0</tlib-version> 
					<short-name>bar-baz</short-name> 
					<tag-file> 
						<name>demo</name> 
						<path>/WEB-INF/tags/depaul/j2ee/demo.tag</path> 
					</tag-file> 
				</taglib>

In a tag file, the tag directive is used to define the tag itself. All the attributes are optional, but it allows some refinement of the tag behavior

The attribute directive defines the attributes of the tag, just like the attributes of a classic tag. The type and name are defined - along with other options.

The variable directive allows scripting variables to be created and exposed to the calling page, just like classic tags.

Tag files are not in widespread use yet, mainly because the 2.0 spec is not in commercial servers yet. But as you can see, it is a lot easier to create tags this way, and for many application developers, this may become a quick way to break the views up into smaller reusable components.

JSTL [19/27]

The JavaServer Pages Standard Tag Library (JSTL) encapsulates, as simple tags, core functionality common to many JSP applications

JSTL is hosted at Jakarta - along with many other useful tag libraries

JSTL, unlike the other libraries, is standardized through the Java Community Process (JCP).

JSTL comes in two versions:

JSTL is the origin of the Expression Language that is now standard in JSP 2.0, so you can use the EL in any JSTL 1.0 tags in a JSP 1.2 container, but the EL is not available outside of JSTL tags (like in a JSP 2.0 container).

To deploy the JSTL, just follow the same directions as for any tag library.

JSTL tags [20/27]

JSTL comes in 4 libraries:

  1. Core library - c
  2. XML processing library - x
  3. Internationalization (i18n) library - fmt
  4. Database Access (SQL) library - sql

Core is for management of variables, iteration, output, conditional logic

XML processing is for parsing, selection of XML, XSTL transforms, logic based on XML data

The i18n library supports formatting of things like currency, dates, and numbers, as well as localized output of content based on Locale

The SQL library is not meant to promote good design of database based apps, but provide for easy access to databases and presentation of the data, without a large amount of abstraction.

Struts overview [21/27]

We have discussed a little bit of the MVC architecture as we discussed integrating servlets and JSPs. However, it is considered best practice to use a framework that helps enforce the design guidelines of MVC, instead of having developers write a web application from scratch.

Model 1 vs. Model 2

There are a number of MVC frameworks available for J2EE, but the most popular is definitely the Struts framework from the Apache Jakarta project.

A web framework usually provides:

Struts Model Components [22/27]

The Model represents the internal state of the application (across page hits), and the various actions that can be taken on the system. Typically, this means integrating with a backend system, or a database, or an LDAP server, or an EJB. It could be just about anything that you could think of.

Struts uses the concept of an Action to interface with these components. Note that this doesn't mean that actions should contain all of your code, but the action is the Struts component that interfaces with your back-end code.

In general, your model should be developed using standard OO practices, and written using a component model that can be scalable, robust, secure, etc. For your purposes as a J2EE developer, this usually means either POJOs (Plain Old Java Objects) or EJBs, depending on your needs. The goal of Struts is not to model your specific environment and needs, but rather be a generic framework for web application development.

Struts View Components [23/27]

One of the great advantages to using a framework is the many helpful components in the View layer of the application. For Struts, this is:

Struts Controller Components [24/27]

The controller portion of Struts is the meat of the framework.

The ActionServlet is the controller. This servlet is registered via the web.xml file to handle all the requests for Struts (usually via a url mapping). The controller does the following:

The mapping between the view and model is all done in a configuration file, struts-config.xml. This file drives the behavior of the controller servlet. The controller forwards the request and response to the RequestProcessor for the module involved and delegates the handling to it.

Each form submitted by the user is representad as a Struts ActionForm. This is basically a JavaBean that will be populated by the framework with the data filled in by the user. Struts takes care of some of the conversion from the strings in HTTP to Java objects. The developer writes these forms in Java, or creates a DynaActionForm via an XML configuration file.

Once a form is populated and validated, the data is submitted to an Action. The Action is responsible for interacting with the model components, and then forwarding to the correct view. This is done via the execute method. The Action is essentially the same thing as a servlet, so all threading issues still apply!

Struts configuration example [25/27]

Here is an example struts configuration file.


				
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE struts-config PUBLIC
         "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
		            "http://struts.apache.org/dtds/struts-config_1_2.dtd">

<!--
  Default configuration file for examples application.
  Each module also has its own struts-config under: /WEB-INF/$MODULE/
  @version $Revision: 1.9 $ $Date: 2004/09/07 02:50:06 $

-->
<struts-config>
  <data-sources />
  <form-beans type="org.apache.struts.webapp.examples.CustomFormBean">
      <form-bean name="example" type="org.apache.struts.webapp.examples.CustomFormBean" >
      <set-property property="example" value="EXAMPLE" />
      </form-bean>
  </form-beans>
  <global-exceptions />
  <global-forwards type="org.apache.struts.webapp.examples.CustomActionForward">
      <!-- utilize a custom ActionForward as an example only -->
    <forward name="welcome" path="/welcome.do">
         <set-property property="example" value="EXAMPLE" />
     </forward>
   </global-forwards>
  <action-mappings type="org.apache.struts.webapp.examples.CustomActionMapping">
    <action path="/welcome" forward="/welcome.jsp" >
        <set-property property="example" value="EXAMPLE" />
    </action>
  </action-mappings>
  <message-resources parameter="MessageResources" />
</struts-config>

JavaServer Faces overview [26/27]

JavaServer Faces is a framework for building J2EE UI components. The framework provides a tag library for creating JSF interfaces within a JSP. JSF is a specification released under the Java Community Process (JCP) as Java Specification Request (JSR) 127.

JSF is not an MVC framework, but rather a UI framework. Struts can be configured to work with JSF today, by using JSF instead of Struts view components in the View portion of the application.

JSF provides a set of reusable server side components. These components are richer than the standard HTML forms provided by Struts and HTML. The components work off of an event handling concept, similar to Swing. The components automatically populate themselves with the correct state for the server side instance of the component.

One benefit of JSF is the ability to render different types of markup using the same component. This allows one component to be used for different devices or browsers, which can be a sort of "holy grail" of web application development.

The future success of JSF most likely depends on integration with Struts and the need for increased sophistication in web based applications.

Assignment [27/27]

To be provided in class

Revised: 10/2/2004