beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: [PATCH] BEEHIVE-974: Allow users to define their own tree renderer
Date Tue, 18 Oct 2005 15:58:48 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message