You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shale.apache.org by "Gary VanMatre (JIRA)" <ji...@apache.org> on 2006/08/03 06:02:21 UTC
[jira] Resolved: (SHALE-24) [Shale] No clay component configuration
for MyFaces Tomahawk
[ 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.
<context-param>
<param-name>
org.apache.shale.clay.COMMON_CONFIG_FILES
</param-name>
<param-value>
classpath*:META-INF/tomahawk-1_1_1-config.xml, /WEB-INF/clay-config.xml
</param-value>
</context-param>
Ryan, thank you for your continued support and valued contributions.
> [Shale] No clay component configuration for MyFaces Tomahawk
> ------------------------------------------------------------
>
> Key: SHALE-24
> URL: http://issues.apache.org/struts/browse/SHALE-24
> Project: Shale
> Issue Type: Bug
> Environment: Operating System: other
> Platform: Other
> Reporter: Ryan Wynn
> Assigned To: Gary VanMatre
> Fix For: 1.0.3
>
> Attachments: test-tomahawk.jar, tomahawk-view-config.xml
>
>
> Attached is a base configuration file for use with Clay for the MyFaces
> Tomahawk components.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Resolved: (SHALE-24) [Shale] No clay component configuration for MyFaces Tomahawk
Posted by Mike Kienenberger <mk...@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.
On 8/3/06, Craig McClanahan <cr...@apache.org> wrote:
> On 8/2/06, Gary VanMatre (JIRA) <ji...@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
>
>
Re: [jira] Resolved: (SHALE-24) [Shale] No clay component configuration for MyFaces Tomahawk
Posted by Craig McClanahan <cr...@apache.org>.
On 8/2/06, Gary VanMatre (JIRA) <ji...@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