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
