On 8/2/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> 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?
Yes, we will need some facelets java classes arranged by component.
I don't really have any opinions on what that layout should be.
> 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.
Yep.
Well it seems to be on ibilio as well. This works for me:
<artifactId>jsf-facelets</artifactId>
<version>1.1.11</version>
Even better! That's the latest version.
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.
Yes, it'll be detected automatically unless you're running certain
versions of OC4J. :-)
All of these mappings are defined on the facelets wiki page.
http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk
There've been some attempts to create a file, but this is such a
moving target (so long as we don't have native facelets support) that
I recommend using the wiki code text instead. Instead, this config
file should be autogenerated. I think I remember seeing that Manfred
had resurrected the code generator before I left on vacation.
We definitely do not want to provide a config file in the jar until we
have 100% compatibility as it'll be hard to override it (you'd have
to edit the jar).
