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
