The definition of objects for use on the view tier is conceptually platform independent. A class is defined with a variable that provides access to its instance. Then there is a question of what scope the instance would live in.

The scopes are generally application, session, request and page, in the order of their width; application scope being the widest. This is however not universal. For component platforms that keep the page state, this would be kept across requests. Furthermore, there could be a conversation scope across multiple pages. Notwithstanding, the concepts here are relatively uniform across the platforms.

For Struts the objects defined could take three forms. The first being 1) the form bean, this type of objects play a major role in the transfer of data, as well as implementation of the validations on the platform.

2) Secondarily, objects could be created in the action classes, place in specific scopes, and exposed to the view tier. Also, there are intrinsic objects like the request, session, cookie, etc. that are automatically available on the page.

3) It is also possible to define and create objects within the code for the page. The reason for this could be partly due to encapsulation. If the object is purely for the view, it could be simpler to define and instantiate within the view code. These could involve redefinition to expose inner objects within objects of the first or second type.

As we shall see later, the implementations involved in the three types are different.

The three types have characteristics that distinguish them. The form bean must be subclasses of specific Struts form bean base classes. Objects of the second type could be part of the model. The last category, the page object, should have page scope, whereas the other types should have scopes of request or wider.

Although, the tags for defining page objects do not restrict the scope of the object created, it is contrary to the concept of MVC to create object for use by other pages, within a page. It could also be a source of error, should the defining page not be traversed.

The implementation aspects of these types of objects are discussed below.

Form Bean

The information needed for this declaration is easy to map from the descriptor, as shown below.

For the declarative form bean definition, an example is shown below.

The corresponding entry in the Struts configuration file would be as follows:

<form-bean name="categoryForm" type="com.example.CategoryForm"/>

This would record the transfer object in the configuration file, which the controller manages the life cycle.

Struts also provided for form objects that are declared purely in XML. These are called DynaForms, and example is shown below.

  <form-bean name="categoryForm"
    	type="org.apache.struts.validator.DynaValidatorActionForm">
    <form-property name="categoryId" type="java.lang.String"/>
    <form-property name="name" type="java.lang.String"/>
    <form-property name="description" type="java.lang.String"/>
   </form-bean>
  

NOTE: The types for the properties could be deduced from the conversion-type entry for the elements in the element descriptor.

As mentioned earlier, the form bean must extend one of the base classes in the table below. There is a set of base classes for object based form bean, and another set used with the XML configured beans. The choice of base classes would determine whether Struts validations could be invoked, and the scope of such validation specification.

 NOTE: dWebSpec specification page-scope should be construed as action scope for the Struts platform.

Scope

Out of the attributes listed for the definition of the objects, one of these has not been applied: the scope. What should be understood is that the life of the form is tied to the action that it is associated. It is within the actions definition, as shown below, that the scope is entered.

  <action path="/categoryData"
  	type="com.struturewebtech.example.northstorm.actions.CategoryDataAction"
  	name="categoryForm" scope="request" validate="true"
  	input="/pages/categoryData.jsp">
  		<forward  name="list" path="/pages/categoryList.jsp" />
  </action>
  

Other

Object could be defined and created within any action class. It is still important for such definitions to be included in the descriptors. There is no declarative or page representation of such bean creation. The explicit inclusion in the descriptor would allow the evaluation of the dependencies for the page. For instance, the action class that creates such objects must be called before the page is rendered, if such objects are required.

Page

For the definition for object used on the page, the descriptor attributes are similar to global definitions. One main difference is that the page object could specify a source or parent object. Struts form bean declaration does not allow hierarchy, as such the parent or source object would be irrelevant. For the page object, a global object, either form-bean or others, could be the parent or source.

The implementation of such definitions involve the bean define tag; example shown below.

  <bean:define id="product"
           toScope="page"
           name="orderDetail"
           property="product"
           type="com.struturewebtech.example.Product"
           scope="request" />
  

The correspondence between the behavior descriptors and the bean define tag attributes are shown in the table below:

NOTE: It is possible to define an object on the page that could by other pages, by setting the scope to session or wider scope. This is however inadvisable especially for future maintenance of the application. If other pages use this object, its availability would depend on whether the page that created the object was first traversed.