cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject [cforms] Custom Binding.
Date Mon, 29 Mar 2004 14:06:40 GMT
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)

- 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 

<fb:custom class="..." id="" path="" >

that would allow to customise the instantiated binding through bean-like 

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"
            id="widget-id" path="context-path">
     <yn:myProps xmlns:yn="">
       .. nested config ..

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 

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.

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

View raw message