>Hi > >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? > >1. ><component jsfid="view" componentType="javax.faces.ViewRoot" >rendererType="...."> > >2. > <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... >Hermod Gary
