To me, this seems like a fine place to start. If I was using this, I wouldn't want to be forced to provide a factory or some other OO construct merely to change the formatting. Just my 2 cents.
Rich Carlin Rogers 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > > >
