cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [cforms] Custom Binding.
Date Mon, 29 Mar 2004 17:13:13 GMT
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.

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?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message