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