beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: Control of white space in the NetUI tree rendering...
Date Wed, 05 Oct 2005 00:30:38 GMT
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 "&nbsp;" 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 &nbsp; characters and line breaks.
> > > > >
> > > > >The current TreeRenderer creates white space that may not be
> desired
> > > in
> > > > two
> > > > >ways. First, there are places where the "&nbsp;" 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 "&nbsp;" 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
> > > > "&nbsp;"
> > > > >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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message