Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <403132C3.60405@apache.org>
Date: Mon, 16 Feb 2004 22:14:43 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CForms "static final" widget definitions
References: <20040213185359.GG356@keow.org>
In-Reply-To: <20040213185359.GG356@keow.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.

>There is an issue, however, with recursive forms. An example of a recursive form is the sample "Form Model GUI" at http://localhost:8888/samples/woody/
>For this type of form, the widget definitions form a cyclic graph instead of a tree of definitions. This makes "static final" definitions harder to create, because there are some widget definitions where both definition objects must be created before either object can finish initiallizing its list of child definitions.
>
>Working with Marc before his vacation and with Antonio a couple of days ago we have designed a solution.  The "assistant" concept in the binding can be adapted for use with the form model. Please see the Assistant inner class in the file JXPathBindingManager.java to see what I am talking about.
>
>The DefaultFormManager would have its own Assistant inner class and an instance of it would be passed to the definition builder classes.  The builder classes would then call methods on the Assistant object to setup the current context and then pass the Assistant object to the constructor method of the WidgetDefinition being built.
>
>The definition's constructor calls the Assistant's "WidgetDefinition[] getChildDefinitions()" method to have the child definitions transparently either built or looked up in the cache, without needing to know what builder objects are responsible, because the lookup of the builder objects and the tracking of the context for the builder objects is hidden behind the generic Assistant interface.
>
>Another issue with "static final" definitions is that all of the configuration information must be passed to the definition's constructor, rather than be setup by later calls to the definition's methods.
>
>Several options for passing the config data:
>  As a Map (my personal preference):
>    WidgetDefinition definition =
>        new SomeWidgetDefinition(map, assistant);
>  Via the assistant:
>    assistant.setConfig(map);
>    WidgetDefinition definition =
>        new SomeWidgetDefinition(assistant);
>  Separate parameters:
>    WidgetDefinition definition =
>        new SomeWidgetDefinition(
>            foo, bar, baz, assistant);
>
>WDYT?
>  
>

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

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

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com