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.

<managed-bean>
         <managed-bean-name>customerOrderBean</managed-bean-name>
         <managed-bean-class>com.example.CustomerOrder</managed-bean-class>
         <managed-bean-scope>session</managed-bean-scope>
</managed-bean>

<f:loadbundle basename="LocalizationResource" var="bundle"/>

<validator>
         <validator-id>FormatValidator</validator-id>
         <validator-class>com.example.FormatValidator</validator-class>
 </validator>

<converter>
         <converter-id>creditCardConverter</Converter-id>
         <converter-class>com.example.CreditCardConverter</Converter-class>
</converter>

SEAM Enhancements

Managed Bean

It is the same declarations allowed in the faces-config.xml tat Seam provides facilities for with annotations.

For managed beans, the mappings to dWebSpec behavior attributes to the annotations are shown below..

Example of such specification is shown below.

The corresponding entry using Seam annotations would be as follows:

package com.example;

@scope("session")
@name("customerOrderBean")
class CustomerOrder {

Dependent Objects

The annotations described above are for the "managed components". These result in objects with framework managed life-cycle that are exposed to the view tier within contexts.

There is another mechanism for exposing objects to the view tier, using "outjection". With this, the parent object is in charge of the initial creation of the object; thereafter these objects have their own independent exposure within contexts. These are dependent object, since they depend on a component for the start of their life-cycle.

NOTE: There is also the mechanism of injection, as popularized by the Spring Framework; this assist in injecting dependencies to the components in a scheme that is not necessarily exposed to the view tier, as such not subjects for the behaviors.

For dWebSpec specification, an object is dependent, if in it definition it has data-source. The data-source would have influence on its life cycle. The implementation transformation for dependent objects is shown below.

Example of such specification is shown below.

The annotation for this specification would show up in the parent class as shown below.

@out("session") OrderTypes orderTypes

NOTE: There is a choice between applying the annotation to the field or to its getter method.

Managed Beans Types

We have shown the declaration of managed beans; however there are different categories of such objects. These are mainly

The designations of these categories are not part of dWebSpec specification, which only capture the common denominators which is the class and object. Although the details attribute could be used to specify the categories, it should be noted that the aim of the behavior descriptor is integration. The true specification of the managed component would reside in the model specifications.

Validator

The specification of the validator classes is almost non-distinguishable from those for other objects. The point is that they are only applicable for validations and subscribe to specific interface.

The corresponding annotations are shown below:

package com.example;

@Name("formatValidator")
@BypassInterceptors
@Converter
class FormatValidator {

Converter

The specification of the converters classes is almost non-distinguishable from those for other objects. The point is that they are only applicable for conversion and subscribe to specific interface

The corresponding annotations are shown below:

package com.example;

@Name("creditCardConverter")
@BypassInterceptors
@Converter
class CreditCardConverter {