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="http://yourspace.org/specific-binding-ns";>
.. 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.
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
