beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <>
Subject Re: [PATCH] BEEHIVE-974: Allow users to define their own tree renderer
Date Mon, 17 Oct 2005 22:32:32 GMT
I have one quick (and general) question to ask here.  Are we all
comfortable with having classnames in tag attributes (vs. databinding to
objects when necessary, and otherwise controlling rendering through
normal value attributes)?  It strikes me as strange, but I haven't come
up with a hard argument against it.

In general, is this something we want to do?  Does anyone else have the
same reaction to this?  One alternative is to require databinding to
some object that provides the right functionality.

In any case, I think we should decide this and be consistent across the


Carlin Rogers wrote:

>I created a JIRA issue to cover the changes discussed earlier this month in
>the dev alias about allowing control of formatting and white space in the
>NetUI tree rendering. The outcome I came away with was to provide a way to
>override the default NetUI TreeRenderer implementation. The following is a
>description I included in the JIRA issue along with a patch.
>...First off, I refactored the TreeRenderer class and its render() method so
>that it can more easily be extended allowing simple overrides of methods
>that format and control white space surrounding the elements that make up
>the markup for a tree node. There are now prefix and suffix routines used to
>append formatting (or additional markup if desired) around each of the
>components in the markup of a node.
>The <netui:tree> tag has been modified to include a new attribute for
>setting a desired TreeRenderer to use on the given tree. In addition, the
>beehive-netui-config schema, ConfigUtil, JspTagConfig, and TagConfig classes
>have been modified such that NetUI can be configured with a different
>default tree renderer, extending the NetUI TreeRenderer, for the Web
>application. It is an optional configuration and the config has our
>TreeRenderer as a default value. This gives an app developer two options.
>They can override the NetUI TreeRenderer for the entire application and
>override it on a tree by tree bases. A renderer named in the <netui:tree>
>tag attribute will always be used regardless of the renderer in the NetUI
>The TreeRenderer used to have some package protected derived classes used
>for handling issues specific to the execution of NetUI code path. There was
>a renderer for the actual tag and a servlet version for the XmlHttpRequest
>via the TreeCRI. Instead of having two different renderers and worrying how
>or if they'd be extended and the desired special handling would be managed,
>this functionality was moved down to a TreeRenderSupport object that was set
>on a given TreeRenderer. Then, no matter the TreeRenderer, we'd delegate the
>special handling to either of two subclasses of the support object to handle
>tag or XmlHttpRequest specific issues... such as error reporting.
>The patch also includes a new test to ensure the renderer overriding works
>for runAtClient and expandOnServer.
>In reviewing this patch...
>- Do I need to expose more of the TreeRenderer data and methods as protected
>rather than private to allow for better sub classing?
>- How or will we version the netui config schema in v1.1 to manage the new
>optional element?

View raw message