Difference between revisions of "Composite Type Descriptor"

Revision as of 13:01, 3 October 2006

Background

At runtime, the EL symbol resolution supports the ability to coerce a symbol into one or more appropriate types. For example, consider the following the expression:

#{var.property}

Furthermore, suppose that var resolves to a managed bean class defined like this:

   public class MyBean implements java.util.Map
   {
      ...
      // has a bean property called 'property'
      public String getProperty()
      {
          return this.name;
      }
      ....
    }

With the default symbol resolution mechanisms in both JSF 1.1 and 1.2, the bean property called property will never be referenced because the class implements Map.

In the default property resolver for JSF 1.1, the resolution logic works something like this:

   public Object getValue(Object obj, Object property)
   {
       if (obj instanceof java.util.Map)
       {
           return ((Map) obj).get(property);
       }
       else
       {
           return getBeanProperty(obj, property);
       }
   }

and in the case of JSF 1.2, the default ELResolver chain will produce a similar result since the MapELResolver is always added to the chain before the BeanELResolver. (Note also that the case is similar for Lists and Arrays and may also be true other custom symbol types).

In order to support fact that different objects from the same symbol source (i.e. Managed Beans) may be treated differently depending on what interfaces and other meta-information they support, the EL tooling needs the concept of a composite type descriptor.

Existing Architecture

The existing JSF 1.1 tooling (in WTP 1.5.x), supports the concept the of a type descriptor on each symbol to describes emulate its runtime type behaviour: