Actually, my opinion is that we should use some type of Dependency Injection, but currently there is no dependencies on things like Spring, and I don't think this feature is significant enough to push us in that direction. If we had a bunch of these type behavior (which I actually think we do) then I'd prefer a design that used a name that was looked up through dependency injection. I just don't think adding this type of stuff to the netui-config file as a general solution is a good thing. We do have the attribute to set the renderer for the full webapp in there, but I don't want to start pushing DI behavior into it.
On 10/17/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > I have one quick (and general) question to ask here. Are we all > comfortable with having classnames in tag attributes (vs. databinding to > objects when necessary, and otherwise controlling rendering through > normal value attributes)? It strikes me as strange, but I haven't come > up with a hard argument against it. > > In general, is this something we want to do? Does anyone else have the > same reaction to this? One alternative is to require databinding to > some object that provides the right functionality. > > In any case, I think we should decide this and be consistent across the > board. > > Rich > > 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 > > > > > > >
