I think their will be exactly one or two alternative renderers and they will
be shared across all page flows/pages. We've seen cases where there are
hundreds of page flows/page/trees. Seems that having a single named thing to
represent the tree style is indeed simpler.
With that I'll agree we just disagree.
On 10/18/05, Rich Feit <[EMAIL PROTECTED]> wrote:
>
> I agree that having support for DI across-the-board is a good thing. I
> just think the non-loosely-coupled solution is simpler. :) In all
> cases, there's code that has to be written (the rendering class
> itself). If you can bind to an instance, then your page flow can reuse
> the same class with tweaked parameters, and can create one-off inner
> classes if necessary. It all happens in one place.
>
> In the JSP:
> renderer="${pageFlow.treeRenderer}"
>
> In the page flow controller:
> public TreeRenderer getTreeRenderer() {
> return new MyTreeRenderer([init values]); // or some static
> instance, or an instance inner class, whatever
> }
>
> Contrast this with the DI solution, where you *have* to go to a wireup
> file to specify parameters for some named thing.
>
> Am I missing something here? I just can't imagine forcing people to use
> DI just to tweak the rendered output of the tree. And if we're
> proposing having an alternative way to do it, I feel that databinding to
> an instance is better than writing a class name into the tag attribute.
>
> Rich
>
> Daryl Olander wrote:
>
> >This is actually what we do all over the place throught the config file.
> >
> >The advantage of specifying the rendering class in the tag is that no
> code
> >at all has to be written (same for DI if you ignore the definition in the
> >XML file). Databinding requires writting code in every page flow if you
> want
> >to apply a non-default rendering. That is actually heavier weight in my
> >thinking. With DI (or specifying the class) no code is written in the
> >PageFlow, the rendering is named and looked up. This is a much nicer
> >solution to specifying the name of the class because it loosely coupled.
> >Both the page flow solution and the class name as attribute are not.
> >
> >On 10/18/05, Rich Feit <[EMAIL PROTECTED]> wrote:
> >
> >
> >>OK, I could see a layer that allowed all of these types of things to be
> >>set through DI. But I also see value and simplicity in our current
> >>databinding-to-instances approach. Are we saying that the *only* way to
> >>control whitespace around tree elements would be to create some class
> >>and wire it up through DI? This seems heavy to me -- all of a sudden
> >>you *can't* just do your page editing within your page and page flow.
> >>
> >>If we're talking about a change across the entire tag set, could we
> >>consider offering both methods (databinding and DI) in all cases?
> >>
> >>Rich
> >>
> >>Eddie O'Neil wrote:
> >>
> >>
> >>
> >>>Ah, that's right -- this part of the tree works differently than it
> >>>does in the data grid. The effect is the same -- the dependent object
> >>>is referenced by some name from the tag and the tag could take care of
> >>>calling out for the injection. The grid could do the same thing in
> >>>that case.
> >>>
> >>>In order to do this, NetUI would need a generalized way of calling
> >>>out to a DI implementation a la the ControlFactory abstraction.
> >>>Probably worth building that as it would also give us a hook for how
> >>>to wire-in ways of injecting Controls, Spring Beans, and other
> >>>dependencies into Page Flows, UI elements, and so on.
> >>>
> >>>But, I agree that there's no reason to add more stuff to the NetUI
> >>>config XML document -- this is a more scalable, flexible, and
> >>>cusomizable solution.
> >>>
> >>>Eddie
> >>>
> >>>
> >>>
> >>>On 10/18/05, Daryl Olander <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>You would bind to a named object that would be created using DI as
> >>>>
> >>>>
> >>described
> >>
> >>
> >>>>earlier in the thread. It's not injected into the tag, it's assocated
> >>>>
> >>>>
> >>with
> >>
> >>
> >>>>the Tree element through the ITreeRoot interface.
> >>>>
> >>>>On 10/18/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Agreed, that's the ultimate "right" solution here, though it's not
> >>>>>
> >>>>>
> >>clear
> >>
> >>
> >>>>>where the dependency
> >>>>>would be injected in the context of an arbitrary JSP tag. We can't
> >>>>>
> >>>>>
> >>inject
> >>
> >>
> >>>>>this into the tag handler
> >>>>>because of pooling of handlers implemented on some containers. In the
> >>>>>
> >>>>>
> >>case
> >>
> >>
> >>>>>of the data grid, it
> >>>>>would certainly be possible to inject it into the top-level
> >>>>>
> >>>>>
> >>DataGridConfig
> >>
> >>
> >>>>>object that is used
> >>>>>throughout grid rendering, but you'd still need to refer to it
> somehow.
> >>>>>And, not all of our tags
> >>>>>have that same abstraction.
> >>>>>
> >>>>>In lieu of DI, referencing the object is a pretty non-invasive way of
> >>>>>supporting the functionality.
> >>>>>
> >>>>>Eddie
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>Daryl Olander wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I'll go back and say the right solution to these problems is
> >>>>>>
> >>>>>>
> >>Dependency
> >>
> >>
> >>>>>>Injection.
> >>>>>>
> >>>>>>On 10/18/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> >
>
