beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlin Rogers <>
Subject [PATCH] BEEHIVE-974: Allow users to define their own tree renderer
Date Fri, 14 Oct 2005 19:37:56 GMT
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?


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