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"; >
