You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mike Kienenberger <mk...@gmail.com> on 2005/11/23 23:24:43 UTC
tree2 and JFSAttr org.apache.myfaces.tree2.* attributes (MYFACES-760)
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";
Re: tree2 and JFSAttr org.apache.myfaces.tree2.* attributes (MYFACES-760)
Posted by Adam Winer <aw...@gmail.com>.
On 11/28/05, Sean Schofield <se...@gmail.com> wrote:
> On 11/24/05, Mike Kienenberger <mk...@gmail.com> wrote:
>
> > 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.
>
> You are correct about the reasoning. I think we should leave this part alone.
The standard JSF solution is to have a UITree2 component without
getters/setters for anything HTML-specific, and an HtmlTree2 component
that adds those getters/setters (and nothing else) purely for convenience.
If tree2 followed this pattern, and you pointed the facelets tag name at that
subclass, you'd have all you need.
Regards,
Adam Winer
Re: tree2 and JFSAttr org.apache.myfaces.tree2.* attributes (MYFACES-760)
Posted by Mike Kienenberger <mk...@gmail.com>.
Sure. I'm not in any rush, so just let me know when.
On 11/28/05, Sean Schofield <se...@gmail.com> wrote:
> On 11/24/05, Mike Kienenberger <mk...@gmail.com> wrote:
>
> [snip]
>
> > 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.
>
> I guess this is ok.
>
> > 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.
>
> You are correct about the reasoning. I think we should leave this part alone.
>
> > 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).
>
> Probably more trouble then its worth.
>
> > 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.
>
> I guess I don't have any objections if you want to change this. One
> favor to ask though. Can you wait until Mathias and I finish
> refactoring tree2. We are trading patches right now and a major
> change like this would screw things up.
>
> sean
>
Re: tree2 and JFSAttr org.apache.myfaces.tree2.* attributes (MYFACES-760)
Posted by Sean Schofield <se...@gmail.com>.
On 11/24/05, Mike Kienenberger <mk...@gmail.com> wrote:
[snip]
> 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.
I guess this is ok.
> 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.
You are correct about the reasoning. I think we should leave this part alone.
> 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).
Probably more trouble then its worth.
> 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.
I guess I don't have any objections if you want to change this. One
favor to ask though. Can you wait until Mathias and I finish
refactoring tree2. We are trading patches right now and a major
change like this would screw things up.
sean
Re: tree2 and JFSAttr org.apache.myfaces.tree2.* attributes (MYFACES-760)
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <se...@gmail.com> 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 <mk...@gmail.com> 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";
> >
>
Re: tree2 and JFSAttr org.apache.myfaces.tree2.* attributes (MYFACES-760)
Posted by Sean Schofield <se...@gmail.com>.
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 <mk...@gmail.com> 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";
>