Hey Carlin: Could you something about the doc requirements for this feature? Specifically, what sort of doc would you like to see?
thanks, steveh. On 10/14/05, Carlin Rogers <[EMAIL PROTECTED]> 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 > > >
