It's probably worth noting that the infrastructure for native facelets support in Tomahawk is being discussed right now on the MyFaces lists. This would be a great time to jump in and get Clay support set up as well. I don't think we have any myfaces committers who are using Clay, so we'll definitely need assistance for this.
On 8/3/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/2/06, Gary VanMatre (JIRA) <[EMAIL PROTECTED]> wrote: > > [ http://issues.apache.org/struts/browse/SHALE-24?page=all ] > > Gary VanMatre resolved SHALE-24. > -------------------------------- > > Fix Version/s: 1.0.3 > Resolution: Fixed > > This is a resolution for SHALE-24. We have the people here that are > interested in doing the work. Ryan Wynn has contributed two versions of the > clay config for the tomahawk 1.1.1 and 1.1.3 releases. These will not be > loaded by default by can be included using an init parameter. I am absolutely delighted that Ryan was willing to do this work. But, my question is ... why is it done here instead of inside Tomahawk? If a JSF component library wants to claim compatibility with a JSF view technology (Clay or Facelets), it seems reasonable that the library would be the place to manage this sort of thing ... that way, they could declare an optional dependence on a particular version of Clay, or Facelets, and provide the appropriate metadata configuration for each release of the components. Expecting the framework provider (Clay or Facelets) to keep up with each library isn't scalable in the long run. Craig
