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="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.
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.
yes.
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= -- 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]
