shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Gary VanMatre)
Subject SV: Clay, Tomahawk and jscookmenu
Date Tue, 16 Jan 2007 21:04:22 GMT
>Ok, I'm finally having some spare time to look into this. It's no problem
>getting the rendererType from components that extend UIComponentTag. Now
>where do we want to put it in the clay-config?
><component jsfid="view" componentType="javax.faces.ViewRoot"
>  <component jsfid="view" componentType="javax.faces.ViewRoot">
>     <attributes>
>         ...
>         <set name=" rendererType " value="..." /> 
>         ...
>  </component>
>I would guess that 1 is the preferred choice, although that will mean that
>we need to change the dtd.

The second approach would be the best way to handle this.  The problem with the first solution
is that we define converters, validators and listeners as "top-level" XML components.  The
rendererType would just be clutter as a component attribute for anything but a component -
the same as the facetName and id attributes.  I hindsight, these odd-ball component attributes
should have been placed in the attributes container.  We might as well add the descriptions
in the TLD to the Clay config too?

On a tangent, I would like to refactor the beans that hold this information into interfaces
and implementations.  This discussion belongs in another thread but if Clay is given a GA
grade with 1.0.4, I'd like to start moving the Clay trunk to depend on Java 1.5 and target
JSF 1.2.  In order to support all of the JSF 1.2 features, we will need to commit to the new
API's.  If we are locked into 1.5, we can look at annotations as our core metadata.  If this
idea shakes out with the list, I'll need some help (hint, hint ;-).  Your TldToClayconfig
plugin could be altered to generate Java source files with annotations too?

These are just some of my ideas.....  I'd like to here from others about the direction they
would like to see Clay go...


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message