9.4 Extending View Components

There generally is less reason or need to extend components located within the view layer than there is to extend components in the controller layer. Typically, views are written exclusively for an application. For example, it's unlikely that a JSP page written for one application will be used within a different application. This is not always the case, but differences between look-and-feel and content make such reuse improbable. The one area within the Struts view layer where extensions often are created, however, is in the JSP tag libraries.

9.4.1 Extending Struts Custom Tags

The custom tags provided by the Struts framework can be reused across applications and application domains. Therefore, it makes sense that customization and extensions are more likely with these components than with JSP pages. Because the tag handlers are regular Java classes, specialization is achieved through subclassing.

Although you can extend any tag, the HTML tag library is the one that you'll most likely need to customize (mainly because the custom tags within this library have the greatest impact on the view content). Regardless of which tags you extend, you'll need to create your own tag library to hold your tag extensions.

You could modify the Struts tag libraries and include your new tag class, but that would make upgrading to newer versions of the Struts framework much harder. You're better off creating your own tag library that contains just your application's tags.

Once you've created a .tld file for your extensions and registered it with the web application deployment descriptor, you are free to use your tags just as you would any others.

9.4.2 Extending Model Components

Because the Struts framework doesn't provide a great deal of components for the model layer, extensions to these components are better discussed in other Java programming books. However, there are two classes that might be placed into the category of extensible model components. They aren't the best representations of what a model component is, but they are responsible for holding model state.

9.4.3 The UserContainer and ApplicationContainer Classes

I've mentioned the UserContainer and ApplicationContainer classes in previous chapters without defining exactly what they are. These two classes are not part of the Struts framework I created them as part of the example Storefront application. The purpose of these two classes is to store user and application-specific information in instances of these classes, rather than in the HttpSession and ServletContext objects, respectively.

One of the problems with storing data in the HttpSession is that the interface to store and retrieve data from the session object is not strongly typed. In other words, the interface for any data is:

public void setAttribute( someString, someObject ); public Object getAttribute( someString );

The client must be aware of the key at which the data is stored in order to put an object into or retrieve an object from storage. For example, to store and then retrieve a set of permissions using the HttpSession, the methods would look like this:

public void setAttribute( permissionsKey, permissionsSet ); public Object getAttribute( permissionsKey );

The programmer would also need to explicitly cast the return value from the getAttribute() method. Some programmers prefer a more strongly typed interface instead:

userContainer.setPermissions( permissions ); userContainer.getPermissions( );

Here, the client doesn't have to worry about what key the object is being stored under or how it's being stored. It can be an HttpSession object or some other data store; the client unaware of the store method because it's not forced to use the methods of the HttpSession directly.

There's nothing really complicated about the UserContainer class itself. It's an ordinary JavaBean that contains instance variables, along with public getters and setters for the properties. Example 9-5 illustrates a basic UserContainer class.

Example 9-5. A basic UserContainer class

package com.oreilly.struts.storefront.framework; import java.util.Locale; import javax.servlet.http.HttpSessionBindingListener; import javax.servlet.http.HttpSessionBindingEvent; import com.oreilly.struts.storefront.customer.view.UserView; /**  * Used to store information about a specific user. This class is used  * so that the information is not scattered throughout the HttpSession.  * Only this object is stored in the session for the user. This class  * implements the HttpSessionBindingListener interface so that it can  * be notified of session timeout and perform the proper cleanup.  */ public class UserContainer implements HttpSessionBindingListener, Serializable {   // The user's shopping cart   private ShoppingCart cart = null;   //  Data about the user that is cached   private UserView userView = null;   /**    * The Locale object for the user. Although Struts stores a Locale for    * each user in the session, the locale is also maintained here.    */   private Locale locale;   public UserContainer( ) {     super( );     initialize( );   }   public ShoppingCart getCart( ) {     return cart;   }   public void setCart(ShoppingCart newCart) {     cart = newCart;   }   public void setLocale(Locale aLocale) {     locale = aLocale;   }   public Locale getLocale( ) {     return locale;   }   /**    * The container calls this method when it is being unbound from the    * session.    */   public void valueUnbound(HttpSessionBindingEvent event) {     // Perform resource cleanup     cleanUp( );   }   /**    * The container calls this method when it is being bound to the    * session.    */   public void valueBound(HttpSessionBindingEvent event) {     // Don't need to do anything, but still have to implement the     // interface method.   }   public UserView getUserView( ) {     return userView;   }   public void setUserView(UserView newView) {     userView = newView;   }   /**    * Initialize all of the required resources    */   private void initialize( ) {     // Create a new shopping cart for this user     cart = new ShoppingCart( );   }   /**    * Clean up any open resources. The shopping cart is left intact    * intentionally.    */   public void cleanUp( ) {     setUserView( null );   } }

One thing to notice is that the UserContainer class in Example 9-5 implements the HttpSessionBindingListener interface. The methods of this interface allow the UserContainer to be notified when it is bound to and unbound from the session. This allows it to perform any necessary cleanup on the object. An instance of the UserContainer is created for each new user at the time the user enters the application. The UserContainer object itself is stored in the session, and it must have the duration of the session. If the user exits and re-enters the site, a new UserContainer typically is created for that user. The UserContainer also implements the Serializable interface. This is necessary in case the container needs to passivate or transfer the session's contents in a cluster.

The ApplicationContainer is used for a similar purpose, but at the application level, not the session level. It's useful for storing or caching information that is needed by all users across the application. Things such as selection lists, configuration properties, and other non-client-specific data that you need to get once and hold on to are candidates for the ApplicationContainer class. This class is created when the application is first started and destroyed when the application exits.