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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>
>>
>
>
>
