cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] Custom Binding.
Date Tue, 30 Mar 2004 06:41:32 GMT

Sylvain Wallez wrote:

> Marc Portier wrote:
>> Hi all,
>> I recetly experienced the need for a nice and clean introduction of a 
>> custom binding class for the cforms.
>> The idea would be to have an all Java alternative to the flexibility 
>> one gets from the <fb:javascript> binding.
>> Currently I see two ways of operating this:
>> 1/ Custom Binding Class
>> <fb:custom class="my.package.CustomBinding"
>>            id="widget-id" path="context-path"/>
>> This would require that the custom class implements the binding 
>> interface and does the expected 'load and save'-work in a side-effect 
>> free way (bindings are to be cached and reused across threads)
>> Processing:
>> - at build time:
>> the builder responsible for the <fb:custom> tag would instantiate the 
>> class, and wrap that as a child-binding inside a specific 
>> CustomJXPathBinding instance
>> - at run time:
>> the CustomJXPathBinding instance will
>>  - narrow the context to value-object at the @path and
>>  - selects the appropriate widget by @id
>>  - before handing those over to the actual wrapped custom-binding 
>> (load or save)
>> Additionally I've been thinking of allowing nested properties to be 
>> provided:
>> <fb:custom class="..." id="" path="" >
>>   <fb:properties>
>>     <someProperty>someValue</someProperty>
>>   </fb:properties>
>> </fb:custom>
>> that would allow to customise the instantiated binding through 
>> bean-like setters
>> However: the limitations of this proclaimed added flexibility seems to 
>> be of minor value though: no nested config, and all installable 
>> properties need a matching setter taking a value of type String
>> All of which one could more easily prevent by creating a specific 
>> subclass that sets the values in code rather then config?
>> Unless someone makes me see different, the better approach seems to be 
>> to provide a custom builder class with a (must be static) factory method:
>> 2/ Custom Binding Builder
>> <fb:custom builder="my.package.CustomBindingBuilder"
>>            method="factoryMethod"
>>            id="widget-id" path="context-path">
>>   <fb:config>
>>     <yn:myProps xmlns:yn="">
>>       .. nested config ..
>>     </yn:myProps>
>>   </fb:config>
>> </fb:custom>
>> This would assume that the customBindingBuilder has a static method 
>> called 'factoryMethod()' and possibly an overloaded version taking a 
>> DOM Node holdig the config.
>> That method is expected to return an instance of type binding (in fact 
>> people might consider adding the static factory method on that class 
>> itself)
>> Apart from who creates the instance the processing of this case would 
>> be  exactly the same as the one above.
>> I was planning on adding this shortly, if anyone has additional 
>> suggestions on either features and/or naming they're very welcome.
> The effect of using a CustomBindingBuilder can actually be considered as 
> a local augmentation of the BindingBuilderSelector, not requiring a 
> change to the global xconf file. So from a design point of view, this 
> seems to be more consistent than directly instanciating a Binding class.


> However, it adds more work to the developper as an additional class is 
> needed and more intimate knowledge of the binding framework is required.

yes, that is why I think the other case remains valid for some users

plus: note that you don't really need a separate class, it could be a 
factory-method on the same one!

> So I was thinking that maybe a mid-term solution would be to use the 
> Binding class (and not Builder), but pass it the DOM as a Configuration 
> if the class implements Configurable?

hm, maybe we should continue down the path and do the same for the 
predefined bindings?

on the other hand I really like how the binding objects today are 
(mostly) immutables, so this would break that filosophy somewhat and I 
really think we should document this with a strong advice to make the 
classes immutable (and threadsafe)

> Sylvain

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message