>From: "Mike Kienenberger" <[EMAIL PROTECTED]> 
>
> 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. 
>

Humm, I would be willing to start a project in the shale sandbox that was 
targeted at converting the tomahawk component examples into jsp/xml and clay 
templates.  Clay supports html namespaces too.  This is a new feature and would 
be a good method of working out the issues.

I don't have the strength to try to do this on the myfaces JIRA.
 

> On 8/3/06, Craig McClanahan wrote: 
> > On 8/2/06, Gary VanMatre (JIRA) 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 don e 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. 
> > 

Maybe in the long run Shale should not host these configurations but it's a 
short term strategy to build momentum.  

The RI only demands that a component library support JSP.  IMO, if Clay can not 
capture the attention of the component providers,  we can't expect them to  
invest the time in providing native support for something that the RI doesn't 
embrace.


> > Craig 
> > 

Gary

> > 

Reply via email to