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 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.

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

Reply via email to