beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers (JIRA)" <>
Subject [jira] Updated: (BEEHIVE-974) Allow users to define their own tree renderer
Date Fri, 14 Oct 2005 19:29:45 GMT
     [ ]

Carlin Rogers updated BEEHIVE-974:

    Attachment: j974-patch.txt

Attaching a patch to support overriding the NetUI tree renderer.

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?

> Allow users to define their own tree renderer
> ---------------------------------------------
>          Key: BEEHIVE-974
>          URL:
>      Project: Beehive
>         Type: Improvement
>   Components: NetUI
>     Versions: V1
>     Reporter: Carlin Rogers
>     Assignee: Carlin Rogers
>      Fix For: 1.1
>  Attachments: j974-patch.txt
> From the email thread on the beehive dev list, there was a discussion about how to allow
control of formatting and white space in the NetUI tree rendering. Some folks want to completely
control white space in the tree rendering using CSS and/or image padding and not have the
"&nbsp;" entities, space characters, and line breaks in the node markup. The discussion
led to a suggestion to allow overriding the default NetUI implementation of the TreeRenderer.
See the "Control of white space in the NetUI tree rendering..." thread from early October
in the beehive dev list.
> I will attach a patch for review and will describe some of the detail in the design.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message