Right; the data grid does something similar with:
<netui-data:dataGrid ... dataGridConfig="${servletContext.fooGridConfig}">
...
</netui-data:dataGrid>
this allows the page author to define a data grid config object that
could be shared between data grids in a site as a way to provide a
single point of configuration for a look & feel, pager renderer, and
behavior for a type of grid. They can be shared across users by
putting them into ServletContext.
So, there's precedent for doing it this way, and it's worked out
pretty well. :)
Eddie
On 10/18/05, Rich Feit <[EMAIL PROTECTED]> wrote:
> Right, I was suggesting something like this:
> renderer=${pageFlow.treeRenderer}
>
> Often it wouldn't need to be connected to instance state, but that
> doesn't strike me as out of bounds. And it would line up better with
> the way we do things elsewhere (e.g., the way you bind to the tree itself).
>
> Rich
>
> Daryl Olander wrote:
>
> >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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >
>
