cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: CForms "static final" widget definitions
Date Tue, 17 Feb 2004 05:36:18 GMT
On Mon, Feb 16, 2004 at 10:14:43PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> 
> >I would like to make the WidgetDefinition objects be "static final", so 
> >the compiler can help us respect the definitions by preventing us from 
> >changing them in ways that are not thread-safe.
> 
> Uh? Can you elaborate on why some definitions could be not thread-safe? 
> AFAIK, once configured, the widget definitions serve only as factories.

This is also what I understand, but I just want the compiler to help
enforce this design, while still allowing for cyclic definitions.

> I don't understand how "static final" (i.e. forbid subclassing) is 
> related to defining graphs of widget definition.

Oops, I should have said "private final", please see this email
from Marc for more clarity/accuracy in the wording:
  http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107334567813794&w=2
Sorry for the confusion.  Java is not my primary language.  To me
it is like speaking a (slowly becoming familiar) foreign language.

> However, I guess I see the point of definition graphs and this reminds 
> me of the LinkedProcessingNodeBuilder in the treeprocessor: the sitemap 
> is also a graph (i.e. <map:call resource>).
> 
> Building the processing node tree involves two steps:
> 1 - hierarchically creating the nodes (i.e. the widget definitions) 
> according to the document tree structure. In that phase, nodes that have 
> inbound links in the target graph (e.g. map:resources) register 
> themselves on the TreeBuilder (analogous to the assistant) and nodes 
> that have outbound links (e.g. map:call resource) implement 
> LinkedProcessingNodeBuilder and as such are remembered by the TreeBuilder.
> 2 - call each of the LinkedProcessingNodeBuilder's linkNode() method so 
> that actual links are created in order to fully link the graph structure.
> 
> Looking at the BindingManager and its Assistant, I think we can consider 
> them as the two facets of a single service: the BindingManager is the 
> external facet, used by the outside world, while the Assistant is the 
> internal facet, providing services to the various DefinititionBuilders. 
> And that internal facet is responsible for providing the services 
> necessary to build the graph.
> 
> So, continuing the parallel with the TreeProcessor, the Assistant could 
> provide a registerDefinition(name, definition) method and build a list 
> of a LinkedWidgetDefinition instances that are called to establish the 
> graph once the tree is fully built.
> 
> Does this relate to your concern, or am I totally off topic?
> 
> Sylvain

Right on the mark!  Thanks for seeing past the "static" fog.

--Tim Larson

Mime
View raw message