I guess I'm not following this, you can do something like renderClass="${
pageFlow.treeRenderer}" where tree renderer is a string to the class. Are
you suggesting that this actually be an instance of TreeRenderer?On 10/17/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > I agree on both counts. My main question at this point is, should we > use databinding instead? Having the classname in the tag attribute > seems strange to me... and at the very least it's not a pattern that we > use consistently across the tag set. > > Daryl Olander wrote: > > >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 > >>> > >>> > >>> > >>> > >>> > > > > > > >
