beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlin Rogers <carlin.rog...@gmail.com>
Subject Control of white space in the NetUI tree rendering...
Date Fri, 30 Sep 2005 20:51:58 GMT
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