beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hanson <>
Subject Re: [PATCH] BEEHIVE-974: Allow users to define their own tree renderer
Date Mon, 17 Oct 2005 17:56:05 GMT
Hey Carlin:

Could you something about the doc requirements for this feature?
Specifically, what sort of doc would you like to see?


On 10/14/05, 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
> configuration.
> 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?
> Thanks,
> Carlin

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