cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: CForms "static final" widget definitions
Date Tue, 17 Feb 2004 21:12:52 GMT
Tim Larson wrote:

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

:-)

In the meantime, I've understood what you actually meant by "static 
final": you want the widget definition objects to be immutable, i.e. 
that their state cannot be modified after they've been initialized.

A solution for this, as you suggest, is to pass all the required data in 
the constructor to allow having no modifier methods. But this can be 
very constraining in writing these classes. Another way is through 
calling a specific method in the lifecycle of the object that makes it 
read-only and makes all modifiers throw an exception.

public void MyDefinition {
  private boolean readonly = false;
  public void makeReadOnly() {
    this.readonly = true;
  }

  public void setProperty(Object value) {
    if (this.readonly) throw new IllegalStateException("Read only");
    // modify property
  }
}

Note that this has actually nothing to do with the previous discussion 
about building a widget graph, but you're right that enforcing widget 
definition immutability can only be a good thing.

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




Mime
View raw message