> Mike Kienenberger wrote:
> I haven't used JSF enough to see if it fits the same pattern, but the
> component-based frameworks I've used in the past have always made Tiles
> unnecessary. Components are "tiles".
I think that many might prefer using a component XML base technique for page
composition but there will still be people that want to take advantage of the
wizz-bang IDE's being developed for JSF JSP that provide a palette of
components, drag and drop and component based property editors. Tiles would
still be very helpful for JSF/JSP development.
> You build a component representing your layout and stick your other layout
> components in it. Then you reference your layout component from your
> general application pages.
>
Tiles works really well for page layout / composition too, allowing you to pull
together a bunch of page fragments in a declarative way. The strength of my
solution is in building the content of the page fragments to promote reuse. In
the subview XML, each node defined has to tied to a faces component and each
component is associated with a renderer. It's focus is on constructing the
meat of a page and would not allow a mix of HTML and faces component
declaration unless the HTML was represented as a faces component and renderer.
I'll pull from my example where I defined a city/state/zip page fragment. It
has validators and listeners and messages included. The panelGrid component
represents a table with two rows having 4 columns. The second row is for
validation messages. This example is for a agents address and the agent must
live in the state so the state field is a static output value.
<!-- an agent must live in the same state, state is a static field -->
<displayElement elementId="agentCityStateZipPanel" extends="panelGrid">
<attributes>
<set name="columns" value="4" />
</attributes>
<element renderId="1" elementId="outputLabel">
<attributes>
<set name="value" value="City/State/Zip:" />
<set name="for" value="city" />
</attributes>
</element>
<element renderId="2" elementId="inputText" id="city">
<attributes>
<set name="value" value="#{managed-bean-name.city}" />
<set name="size" value="20" />
<set name="maxlength" value="30" />
<set name="required" value="true" />
</attributes>
</element>
<element renderId="3" elementId="outputText">
<attributes>
<set name="value" value="#{managed-bean-name.state}" />
</attributes>
</element>
<!-- 2 types methods for binding change listeners and a converter -->
<element renderId="4" elementId="inputText" id="zip">
<attributes>
<set name="value" useValueLateBinding="true"
value="#{managed-bean-name.zip}" />
<set name="maxlength" value="9" />
<set name="size" value="5"/>
<set name="valueChangeListener" useMethodLateBinding="true"
value="#{managed-bean-name.zipValueChange}" />
</attributes>
<converter elementId="integerConverter" />
<validator elementId="validateLongRange" />
<valueChangeListener elementId="testValueChangeListener" />
</element>
<element renderId="5" elementId="space" />
<element renderId="6" elementId="message" >
<attributes>
<set name="for" value="city" />
</attributes>
</element>
<element renderId="7" elementId="space" />
<element renderId="8" elementId="message" >
<attributes>
<set name="for" value="zip" />
</attributes>
</element>
</displayElement>
In another view, we want to provide a full address where the states are a
droplist and a required field. Using faces and JSP, you would have to copy the
page fragment and make the changes and then use tiles to override at the page
level what fragment you wanted to include. What I'm trying to offer is a
method of reusing and extending the first page fragment. This example extends
the definition overriding the state and adding a validation message.
<!-- extends the agent address making the state a droplist -->
<displayElement elementId="cityStateZipPanelEx"
extends="agentCityStateZipPanel">
<!-- override with a nested element -->
<element renderId="3" elementId="selectOneMenu" id="states">
<attributes>
<set name="value" value="#{managed-bean-name.state}" />
<set name="required" value="true" />
</attributes>
<element renderId="0" elementId="selectItem">
<attributes>
<set name="itemLabel" value="" />
<set name="itemValue" value="" />
</attributes>
</element>
<element renderId="1" elementId="selectItem">
<attributes>
<set name="itemLabel" value="Colorado" />
<set name="itemValue" value="CO" />
</attributes>
</element>
<element renderId="2" elementId="selectItem">
<attributes>
<set name="itemLabel" value="Illinois" />
<set name="itemValue" value="IL" />
</attributes>
</element>
</element>
<!-- add a message for the required state overriding a space -->
<element renderId="7" elementId="message" >
<attributes>
<set name="for" value="states" />
</attributes>
</element>
</displayElement>
> Component-based models allow you to do things differently, and I'm just
> wondering if you're dragging some "old-school" methodologies into it
> unnecessarily. Perhaps the answer is that there's no need to reinvent Tiles
> OR integrate Tiles.
Because the standard use of JSF is using JSP, and all the vendor IDE's support
this, I think the "old-school" method has to be supported and Tiles would add
value there. My hope is to be able to add value with this extension, providing
a tiles like solution for faces page decoration that is just another option and
can be used with other techniques.
Gary
