beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlin Rogers <carlin.rog...@gmail.com>
Subject Re: Control of white space in the NetUI tree rendering...
Date Thu, 06 Oct 2005 20:10:07 GMT
oops, meant to sent to the dev alias...

On 10/6/05, Carlin Rogers <carlin.rogers@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 <dolander@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 "&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