oops, meant to sent to the dev alias...
On 10/6/05, Carlin Rogers <[EMAIL PROTECTED]> wrote: > > Daryl, I think I understand this alternative option of the attribute being > a class name of a renderer rather than a config used by the renderer. A > developer can implement a renderer class and overrirde methods that manage > the formatting for the markup of the node. In this case we'd still have an > element in the NetUI config file for setting a WebApp based renderer and > we'd have a class name attribute on the netui:tree tag. However, we wouldn't > have an attribute for the netui:treePropertyOverride tag as the renderer > is for the entire tree, not a single element. > > I have a few additional questions then about this implementation. For the > expand on server scenario, does the TreeCRI still use the > ServletTreeRenderer? I'm not sure how the TreeCRI would manage to know what > renderer to use? Do we add something to the TreeRenderState or > ITreeRootElement? What do you think? > > > On 10/5/05, Daryl Olander <[EMAIL PROTECTED]> wrote: > > > > I guess I thought this was a property of the renderer not of the tree > > (or subtree)....I guess we could do it that way, it is certainly more > > flexible... > > > > On 10/5/05, Carlin Rogers < [EMAIL PROTECTED]> wrote: > > > > > > OK, good points. Yes, seems that allowing control to provide magic > > > span between images or before/after the label or content is desirable. > > > > > > Daryl, there would be a new element in the NetUI config that would be > > > parallel to the <tree-image-location> element and would be a class name > > > for > > > an implementation of my suggested tree config object, TreeFomatConfig, > > > for WebApp based setting. We'd also add the class name to the > > > InheritableState and have the attributes on both the netui:tree and > > > netui:reePropertyOverride tag to override the config for a given tree... > > > as > > > we do with images. Sound right? > > > > > > Thanks, > > > Carlin > > > > > > On 10/4/05, Daryl Olander <[EMAIL PROTECTED]> wrote: > > > > > > > > In my experience, a CSS solution is difficult, and it's not clear > > > > that it gives you full support. Geting someone full on control of the > > > > markup > > > > between the tree markup would be my choice because we won't get a bug > > > > in the > > > > future saying that someone wants to put some magic span with CSS > > > > inbetween > > > > the images the tree is rendering....One request, my lead to other > > > > requests....Up to you however. > > > > > > > > On 10/4/05, Carlin Rogers < [EMAIL PROTECTED]> wrote: > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
