beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: [PATCH] BEEHIVE-974: Allow users to define their own tree renderer
Date Tue, 18 Oct 2005 02:30:44 GMT
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