shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: [jira] Resolved: (SHALE-24) [Shale] No clay component configuration for MyFaces Tomahawk
Date Fri, 04 Aug 2006 00:53:14 GMT
>From: "Mike Kienenberger" <mkienenb@gmail.com> 
>
> 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

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