> Ah, okay, I see. This capability, which essentially lets you plug
> component attributes (including managed bean properties) into
> components at runtime, is more fine-grained than Tiles and is certainly
> JSF-specific. In fact, a while back, I had a client ask for something
> like this: they wanted to use the same "tile" for different managed
> beans, selected at runtime.
I thought that this complemented the subview that existed in Shale today.
>
> This reminds me of something I've been thinking about for some time:
> Tapestry-like HTML views that dovetail with XML component definitions
> (see Hans' Bergsten's article about dumping JSP with JSF at
> onjava.com). In that case an HTML view references components in a
> component definition file. If you could select a component definition
> file at runtime for a view, I believe you'd have analagous
> functionality to what Gary is proposing here.
>
I think the general idea is similar to Han's but it's not meant to replace JSP
but work with it. I don't think that Han's article provided the same
inheritance capabilities.
In this schema, all components, converters, validators and listeners are
represented by a displayElement node. Display elements are associated to a
faces component using the componentType attribute. Composition can be formed
using the element node. The elementId attribute represents a displayElement
that should be pulled into the definition. The included elements attributes
can be overridden too, kind of like a inner class.
In this example I create a image with a default size called buttonBorder. It
extends the image displayElement that is associated to the faces component.
The buttonBorder displayElement is included in the roundButton displayElement
overriding the value and width attributes (this is what I meant by composition
inheritance - like an inner class)
<displayElement elementId="image" componentType="javax.faces.HtmlGraphicImage"/>
<displayElement elementId="panelGrid" componentType="javax.faces.HtmlPanelGrid"
/>
<displayElement elementId="buttonBorder" extends="image">
<attributes>
<set name="width" value="16" />
<set name="height" value="16" />
</attributes>
</displayElement>
<!-- round button created from a table -->
<displayElement elementId="roundButton" extends="panelGrid">
<attributes>
<set name="columns" value="3" />
<set name="align" value="center" />
<set name="border" value="0" />
<set name="cellpadding" value="0" />
<set name="cellspacing" value="0" />
</attributes>
<element renderId="1" elementId="buttonBorder">
<attributes>
<set name="value" value="../images/top_lef.gif" />
</attributes>
</element>
<element renderId="2" elementId="buttonBorder">
<attributes>
<set name="value" value="../images/top_mid.gif" />
<set name="width" value="24" />
</attributes>
</element>
...
...
--
</displayElement
The cost of fixing-up the inheritance is at application startup. All xml
metadata files are digested, inheritance resolved and circular inheritance
checked, the same approach as struts, faces and shale.
Gary
