beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie O'Neil <ekon...@gmail.com>
Subject Re: [PATCH] BEEHIVE-974: Allow users to define their own tree renderer
Date Tue, 18 Oct 2005 16:20:13 GMT
  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 <dolander@gmail.com> 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 <ekoneil@bea.com> 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 <ekoneil@gmail.com> 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 <richfeit@gmail.com> 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 <richfeit@gmail.com> 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 <richfeit@gmail.com> 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
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >
> >
> >
>
>

Mime
View raw message