On 5/9/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Thomas and I have talked on and off about adding facelets support
natively to MyFaces Tomahawk.
http://issues.apache.org/jira/browse/TOMAHAWK-79
Things that were holding us up in the past were no code generator.
That's now available again, although I haven't had time to look into
using it.
Also, we're waiting for a maven-repository version of facelets to
appear. That should happen shortly as ADFFaces also needs it.
I'll have all next week to beat on Jacob. :)
I think we'll want to make it a separate jar and project because
facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
JSP 2.1 as well. Those don't need to be dependencies for standard
tomahawk use.
FYI, it doesn't depend on the JSF 1.2 RI, and it *definitely*
doesn't depend on JSP 2.1 (or anything in JSP, for that matter).
It does require a javax.el implementation; I don't remember offhand
if it's hardcoded against the Glassfish implementation or if
that's pluggable.
I don't see these as significant advantages to making it a separate
JAR. None of these should be marked as required dependencies for
standard tomahawk use - they should all be marked as "provided"
scope, which avoids the issue.
-- Adam
As for things like tree2, the best solution is to fix them in Tomahawk
rather than add a workaround for facelets. That allows other
alternate view handlers to work as well. Sean checked in a tree2 fix
this week. We still need one for extended data table.
-Mike
On 5/9/06, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> Until now, most people are using the WIKI[1] for getting myfaces to
> work with facelets. I was wondering if we want to make MyFaces include
> support for facelets natively. This should be able to be done in such
> a way to prevent problems for those that do not use facelets.
>
> Option 1)
> Add everything to tomahawk.jar including the TagHandler classes and
> taglib.xml file(s).
>
> This is easiest, and will not cause issues since non-facelet users
> will not be using those classes, and therefore if they don't have
> facelets in their classpath, it shouldn't matter.
>
> Option 2)
> Create a new myfaces jar file (tomahawk-facelets-1.1.2.jar for
> example) that contains only the code and configuration necessary to
> "plug" tomahawk into facelets.
>
> This is possibly more elegant but more of a pain to setup.
>
> Option 3)
> Maintain all this at jsf-comp.
>
> This works, but new users may not know about jsf-comp and it is harder
> to stay in sync with facelet and myfaces version changes (since it is
> not tied into the release cycle).
>
> Since facelets hasn't changed the taglib.xml structure at all, facelet
> version should not be a major issue. This would also make issues like
> what tree2 had a mute point since we could include component handlers
> built in to translate any "non-standard" logic in the Tag classes.
>
> This methodology could be applied to the sandbox as well. Once there
> is some code in SVN I would think myfaces developers could easily
> maintain their configuration for their components as well since there
> would be examples from other components to learn from (so even
> developers without facelets experience shouldn't have any issues).
>
> What do you think?
> -Andrew
>
> [1] http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk
>
