shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [jira] Resolved: (SHALE-24) [Shale] No clay component configuration for MyFaces Tomahawk
Date Thu, 03 Aug 2006 05:23:20 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message