You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Carlin Rogers <ca...@gmail.com> on 2005/09/30 22:51:58 UTC
Control of white space in the NetUI tree rendering...
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
Re: Control of white space in the NetUI tree rendering...
Posted by Daryl Olander <do...@gmail.com>.
The reason I proposed #2 was you could control the markup in anyway you want
for the spots around the tree markup. The default implementation would work
as it does today, but call method to provide the markup for the spots
(" " and "\n"). A simple subclassing of the tree rendering would then
allow full control over these spots.
The factory is in keeping with our general design that this can then be
overridden on a tree by tree bases (by specifying it on the <netui:tree>
tag) or on a WebApp bases through the netui config file.
On 10/4/05, Rich Feit <ri...@gmail.com> 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
> >
> >
> >
>
Re: Control of white space in the NetUI tree rendering...
Posted by Rich Feit <ri...@gmail.com>.
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 <do...@gmail.com> 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 <carlin.rogers@gmail.com > 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 <richfeit@gmail.com > 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
Re: Control of white space in the NetUI tree rendering...
Posted by Carlin Rogers <ca...@gmail.com>.
oops, meant to sent to the dev alias...
On 10/6/05, Carlin Rogers <ca...@gmail.com> 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 <do...@gmail.com> 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 < carlin.rogers@gmail.com> 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 <do...@gmail.com> 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 < carlin.rogers@gmail.com> 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 < dolander@gmail.com> 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 <carlin.rogers@gmail.com > 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 < richfeit@gmail.com > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Fwd: Control of white space in the NetUI tree rendering...
Posted by Daryl Olander <do...@gmail.com>.
---------- Forwarded message ----------
From: Daryl Olander <do...@gmail.com>
Date: Oct 6, 2005 2:16 PM
Subject: Re: Control of white space in the NetUI tree rendering...
To: Carlin Rogers <ca...@gmail.com>
Sucks...It's proper place is the ITreeRootElement but that is an
incompatible change.
What does the community think...You can't add a method to an interface, but
I don't really want to create ITreeRootElementEx or
ITreeRootElementGetAdditionalStuff....
On 10/6/05, Carlin Rogers <ca...@gmail.com> 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 <dolander@gmail.com > 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 < carlin.rogers@gmail.com> 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 <do...@gmail.com> 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 < carlin.rogers@gmail.com> 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 < dolander@gmail.com> 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 <carlin.rogers@gmail.com > 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 < richfeit@gmail.com > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Control of white space in the NetUI tree rendering...
Posted by Daryl Olander <do...@gmail.com>.
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 <ca...@gmail.com> 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 <do...@gmail.com> 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 <carlin.rogers@gmail.com > 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 <richfeit@gmail.com > 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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: Control of white space in the NetUI tree rendering...
Posted by Carlin Rogers <ca...@gmail.com>.
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 <do...@gmail.com> 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 <carlin.rogers@gmail.com > 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 <richfeit@gmail.com > 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
> > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Control of white space in the NetUI tree rendering...
Posted by Daryl Olander <do...@gmail.com>.
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 <ca...@gmail.com> 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 <ri...@gmail.com> 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
> > >
> > >
> > >
> >
>
>
Re: Control of white space in the NetUI tree rendering...
Posted by Carlin Rogers <ca...@gmail.com>.
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 <ri...@gmail.com> 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
> >
> >
> >
>
Re: Control of white space in the NetUI tree rendering...
Posted by Rich Feit <ri...@gmail.com>.
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
>
>
>