Hi Steve, Thanks for looking at this. First, let's see how some of the feedback from the other committers impacts the changes I've put in this patch. If the design remains basically the same, then adding some documentation to the bottom of the NetUI tagsTree.html page, just following the "TreeElement Rendered Contents" section which describes the markup used to render a node. I think that would be a good lead in. The Javadoc for the Tree tags has already been updated but could probably be improved by a review. Thanks!
Carlin On 10/17/05, Steve Hanson <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > >
