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