Rich, Yes, that might be a good idea. I'm also curious about Daryl's thoughts on these changes to the Tree tag.
I guess it becomes a matter of how much control we want to give for formatting the node markup. I identified various white space (space indents and " " entity) and line-break literals used for indent and spacing of the spacer images, connection images (expand/collapse/join lines), item icon, labels, and content. Might be more than just the before-item/after-item/line-break attributes. I'd gone forward implementing a patch for this feature along the lines of option #2 to allow application developers to determine the Strings used as white space to separate each part of the node markup. I have a TreeFomatConfigFactory that checks for a class name of a TreeFomatConfig implementation in the NetUI config file using ConfigUtil. If a class name property exists, the factory will return an instance of it. Otherwise, a DefaultTreeFomatConfig will be returned. The TreeRenderer will use the TreeFomatConfig to get the various prefix and suffix literal String values used to format (beautify) the node markup. In the render() routine I was just going to get each format value and directly write it to the InternalStringBuilder object. I could make separate, protected methods in the TreeRenderer that take a StringBuilderRenderAppender and a TreeFomatConfig, then get the desired format value and append it... Anyway, yes maybe this is too heavy a solution for this feature. let me see what might be the minimal set of netui:tree tag attributes might be. Would these also become part of the InheritableState and we'd have the same attributes on the netui:reePropertyOverride tag to allow individual node control as we do with images? Thanks, Carlin On 10/4/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > Hi Carlin, > > Just wondering if there's another option: have attributes for whitespace > (maybe one for before-item and one for after-item) and line-break on the > netui:tree tag. Would this provide enough flexibility? A factory just > seems so heavyweight for this purpose. What do you think? > > Rich > > Carlin Rogers wrote: > > >I wanted to get some thoughts about the white space in tree rendering. > Some > >folks want to completely control white space in the tree rendering using > CSS > >and/or image padding rather than characters and line breaks. > > > >The current TreeRenderer creates white space that may not be desired in > two > >ways. First, there are places where the " " entity is used for > >presentation purposes, preventing the tag user from controlling spacing > on > >their own. A tag user would like to have the flexibility to solve spacing > >issues rather than have it predefined. In addition, line breaks after > spacer > >images create small gaps after the spacer image. We have the line breaks > to > >make the HTML source readable but some browsers display small gaps. > > > >Some possible options for allowing more control over the white space > would > >be to... > > > >1) Add a new, simple, all or nothing attribute for the <netui:tree> tag > that > >by default would use the same markup today with " " and line breaks, > or > >when set would remove this white from the markup. > > > >2) Create a factory that provides a set of values (Strings such as > " " > >and "\n") that can be used in the markup to manage the white space > between > >the elements that make up a tree node. Each value would have a specific > name > >for it's location within the markup such as between the icon image and > the > >label text. We would have a default class implementation that the factory > >would provide to the renderer. Then, an application developer could > provide > >their own implementation that allows them to determine the String used to > >separate each part of the node markup. > > > >In option #2, would we want this class registered in the > >beehive-netui-config.xml for the application or would it be a new tag > >attribute? I think having it in the class registered in the config file > is > >best so we're not trying construct it on every request. Maybe the factory > >checks once for the config entry and then caches an instance of the class > to > >return? > > > >Please let me know if you have any other thoughts about this issue or > input > >on the design direction. > > > >Thanks, > >Carlin > > > > > > >
