Maybe we're trying to build in too much to provide control over all the individual white space formatting of the node. As far as I know, the basic need was really to remove the white space we add to format/beautify the markup.
With option #1, we could just have a single attribute - maybe "beautifyNode" ;-) - that by default is true and adds the current formatting. When set to false, all the formatting is dropped and the developers would control white space in the tree rendering using CSS and/or image padding, not by providing formatting strings to us. Carlin On 10/4/05, Daryl Olander <[EMAIL PROTECTED]> wrote: > > In looking at this, if we take this approach we should move the other > configurable things into this config object also (image locations, etc)..My > proposal was to just put methods into the rendering base class that would > get the white space which would allow a very simple subclassing of the > rendering the change the whitespace (instead of externalizing it). > > I'm not sure which I prefer....If we do externalize it, I think we should > put all of the NetUI config information related to trees into a single > object so we can name the configurations and using some type of IoC > (dependency injection) to get those configurations. > > On 10/4/05, Carlin Rogers <[EMAIL PROTECTED] > wrote: > > > > 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 > > > > > > > > > > > > > > > > > > > >
