Sure. I'm not in any rush, so just let me know when.
On 11/28/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > On 11/24/05, Mike Kienenberger <[EMAIL PROTECTED]> 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 >
