For most of the remaining problem components, it's simply a matter of
taking care of the generic attributes and making them explicit html
attributes like you did for tree2.
OK so there's not much of a need for this new package directory but we
do need it in a few limited cases right?
The only component I know to be more complicated than fixing
attributes (in MyFaces) or defining method bindings (in facelets tag
handlers) is t:tree. The jsp tag and the component don't use the
same attributes.
Ok. There is the option of not supporting it but it would be nice if
we could say 100% of tomahawk is facelets compatible.
Sounds good. That's what I was planning on doing once someone else
got the maven foundation in place.
By the way, I came across the facelets maven location earlier:
http://wiki.java.net/bin/view/Projects/FaceletsFAQ#Is_Facelets_in_ibiblio_or_anothe
Well it seems to be on ibilio as well. This works for me:
<dependency>
<groupId>com.sun.facelets</groupId>
<artifactId>jsf-facelets</artifactId>
<version>1.1.11</version>
</dependency>
Don't need to do anything for t:popup -- at least the following is
working fine for me.
<tag>
<tag-name>popup</tag-name>
<component>
<component-type>org.apache.myfaces.HtmlPopup</component-type>
<renderer-type>org.apache.myfaces.Popup</renderer-type>
</component>
</tag>
Duh! I forgot to map the component in the facelet taglib. If we
include this mapping in tomahawk.jar facelets will detect it
automatically? I thought I remembered someone starting a config file
for this purpose. If this is possible we should create such a config
file once we are 100% done with facelets compatability.
Sean
