shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: [jira] Resolved: (SHALE-24) [Shale] No clay component configuration for MyFaces Tomahawk
Date Thu, 03 Aug 2006 13:32:01 GMT
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 <craigmcc@apache.org> wrote:
> On 8/2/06, Gary VanMatre (JIRA) <jira@apache.org> 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
>
>

Mime
View raw message