It's not that it can't be done in facelets -- it's that it's kludgy to
handle attributes named one thing on the page tag and another thing on
the component class.
Facelets doesn't require a tag handler class to assign attributes.
It directly reads the attributes off the page text and assigns them to
the component.
So if you name the attribute "org.apache.myfaces.tree2.SHOW_LINES",
then in facelets, the end-user has to use <t:tree2
org.apache.myfaces.tree2.SHOW_NAV="#{whatever}"> on his page.
(You can see how Aaron Aston documented doing this in
http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk).
On the facelets user mailing list, I've seen other users posting that
they edit JSFAttr directly to change the attribute names and recompile
myfaces.
The easiest solution (in my opinion) is to have the tag attribute
names and the component attribute names be the same. Almost all
components in tomahawk and JSF currently have matching names.
Another solution would be to add the getter/setters for these
attributes to the component. I'm guessing that tree2 doesn't do this
because you wanted to keep the html render-specific attributes out of
the component and only access them in the renderer, and I can see the
logic of doing so.
Other solutions would be writing an equivalent facelets tag handler
that aliases "xyz" to "o.a.m.*.xyz" -- However this requires that a
compilable java class be maintained somewhere to support this
translation. (If we decide to go this route, I'd like to see it done
in a o.a.m.tree2.facelets subdirectory, but this will require a
compile-time dependency on the facelets jar).
One thing to keep in mind is that so long as the tag attribute names
and the component attribute names don't match, non-JSP viewhandlers
are going to have to "bridge the gap" in attribute naming somehow.
I'm not sure how Shale/Clay is handling this. Maybe they're calling
the jsp tag directly. Maybe they've already written their own tag
handler. Maybe their users haven't hit the issue yet.
Since these attribute name constants are shared among components (I'm
guessing that's the reason they're globally declared in JSFAttr), I
don't see why they need to have a fully-qualified name. It seems
unlikely that you're going to have a conflict using
o.a.m.tree2.SHOW_LINES and some.other.package.SHOW_LINES in the same
component.
I'd like to see some consistency, but if there's a practical reason
why this can't happen, I understand. However, if the fqn is only used
because it's a good general practice, I'd like us to re-evaluate it in
the context of how these attribute names have to be used in the real
world.
On 11/23/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Mike,
>
> I don't know much about facelets but I'm curious to know what is
> causing the problem. If facelets doesn't support attribute properties
> with '.' characters in the name then IMO that is really the source of
> the problem.
>
> Its considered good practice to have fully qualifies names in your
> constants so that they don't collide with other values. Shale makes
> use of this convention as well (see ShaleConstants class.)
>
> On the other hand, I hate to see our users resort to hacks. Maybe we
> can help the facelets folks resolve the problem in another way. It
> seems too restrictive the way you describe it.
>
> sean
>
> On 11/23/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > Is there a reason why we can't change all of these
> > "org.apache.myfaces.tree2.xyz" attributes to "xyz?"
> >
> > // Tree2 attributes
> > public static final String SHOW_NAV =
> > "org.apache.myfaces.tree2.SHOW_NAV";
> > public static final String SHOW_LINES =
> > "org.apache.myfaces.tree2.SHOW_LINES";
> > public static final String CLIENT_SIDE_TOGGLE =
> > "org.apache.myfaces.tree2.CLIENT_SIDE_TOGGLE";
> > public static final String SHOW_ROOT_NODE =
> > "org.apache.myfaces.tree2.SHOW_ROOT_NODE";
> > public static final String PRESERVE_TOGGLE =
> > "org.apache.myfaces.tree2.PRESERVE_TOGGLE";
> >
> > The "extended" names are breaking alternate viewhandler support (ie,
> > facelets).
> > End users are using a variety of hacks to get around it (custom
> > JSFAttr classes, using the full o.a.m.t.* name as the attribute, etc).
> >
> > While it's also possible to fix this by creating a custom facelet tag
> > handler, it seems like it'd make more sense to just change the
> > attribute name used internally.
> >
> > It looks like there are also three attributes on t:dataTable that
> > should also be changed:
> >
> > // dataTable (extended) attributes
> > public static final String ROW_ID =
> > "org.apache.myfaces.dataTable.ROW_ID";
> > public static final String ROW_STYLECLASS_ATTR =
> > "org.apache.myfaces.dataTable.ROW_STYLECLASS";
> > public static final String ROW_STYLE_ATTR =
> > "org.apache.myfaces.dataTable.ROW_STYLE";
> >
>
