We agree that having a DI option is good.

You're saying we disagree about using a class name vs. databinding to an
instance?

Daryl Olander wrote:

>I think their will be exactly one or two alternative renderers and they will
>be shared across all page flows/pages. We've seen cases where there are
>hundreds of page flows/page/trees. Seems that having a single named thing to
>represent the tree style is indeed simpler.
>
>With that I'll agree we just disagree.
>
>On 10/18/05, Rich Feit <[EMAIL PROTECTED]> wrote:
>  
>
>>I agree that having support for DI across-the-board is a good thing. I
>>just think the non-loosely-coupled solution is simpler. :) In all
>>cases, there's code that has to be written (the rendering class
>>itself). If you can bind to an instance, then your page flow can reuse
>>the same class with tweaked parameters, and can create one-off inner
>>classes if necessary. It all happens in one place.
>>
>>In the JSP:
>>renderer="${pageFlow.treeRenderer}"
>>
>>In the page flow controller:
>>public TreeRenderer getTreeRenderer() {
>>return new MyTreeRenderer([init values]); // or some static
>>instance, or an instance inner class, whatever
>>}
>>
>>Contrast this with the DI solution, where you *have* to go to a wireup
>>file to specify parameters for some named thing.
>>
>>Am I missing something here? I just can't imagine forcing people to use
>>DI just to tweak the rendered output of the tree. And if we're
>>proposing having an alternative way to do it, I feel that databinding to
>>an instance is better than writing a class name into the tag attribute.
>>
>>Rich
>>
>>Daryl Olander wrote:
>>
>>    
>>
>>>This is actually what we do all over the place throught the config file.
>>>
>>>The advantage of specifying the rendering class in the tag is that no
>>>      
>>>
>>code
>>    
>>
>>>at all has to be written (same for DI if you ignore the definition in the
>>>XML file). Databinding requires writting code in every page flow if you
>>>      
>>>
>>want
>>    
>>
>>>to apply a non-default rendering. That is actually heavier weight in my
>>>thinking. With DI (or specifying the class) no code is written in the
>>>PageFlow, the rendering is named and looked up. This is a much nicer
>>>solution to specifying the name of the class because it loosely coupled.
>>>Both the page flow solution and the class name as attribute are not.
>>>
>>>On 10/18/05, Rich Feit <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>      
>>>
>>>>OK, I could see a layer that allowed all of these types of things to be
>>>>set through DI. But I also see value and simplicity in our current
>>>>databinding-to-instances approach. Are we saying that the *only* way to
>>>>control whitespace around tree elements would be to create some class
>>>>and wire it up through DI? This seems heavy to me -- all of a sudden
>>>>you *can't* just do your page editing within your page and page flow.
>>>>
>>>>If we're talking about a change across the entire tag set, could we
>>>>consider offering both methods (databinding and DI) in all cases?
>>>>
>>>>Rich
>>>>
>>>>Eddie O'Neil wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                              
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>                          
>>>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>            
>>>>>>
>>>>>
>>>>>          
>>>>>
>>>
>>>      
>>>
>
>  
>

Reply via email to