You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2004/03/29 16:06:40 UTC
[cforms] Custom Binding.
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.
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] Custom Binding.
Posted by Joerg Heinicke <jo...@gmx.de>.
On 31.03.2004 10:36, Marc Portier wrote:
>>> hm, if SoC is the argument, then shouldn't we consider the who is
>>> doing what discussion?
>>>
>>> my feeling is that touching the xconf is out of question to a lot of
>>> users? They could easily write up a custom-binding and be glad they
>>> never need to learn about the xconf in the first place?
>>
>> I don't know if I follow this argumentation. Having configuration
>> splitted over multiple files might help the user at the beginning, but
>> can lead to a nightmare at the end. But maybe I just want to do
>> anything to perfect :)
>
> the only config part that would make sense on the xconf level is the
> class-name, the rest would be local config that needs to be in the
> binding file anyway (like you say: why scatter it around in different
> places?)
Ok, this convinces me at least partly ;-)
Joerg
Re: [cforms] Custom Binding.
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> On 30.03.2004 08:45, Marc Portier wrote:
>
>> hm, if SoC is the argument, then shouldn't we consider the who is
>> doing what discussion?
>>
>> my feeling is that touching the xconf is out of question to a lot of
>> users? They could easily write up a custom-binding and be glad they
>> never need to learn about the xconf in the first place?
>
>
> I don't know if I follow this argumentation. Having configuration
> splitted over multiple files might help the user at the beginning, but
> can lead to a nightmare at the end. But maybe I just want to do anything
> to perfect :)
>
nope, I think you are right, and I have to admit the xconf is not the
real pain here, but I doubth it would help:
the only config part that would make sense on the xconf level is the
class-name, the rest would be local config that needs to be in the
binding file anyway (like you say: why scatter it around in different
places?)
see: the big goal of this thingy would in fact to throw in a custom
binding when the jxpath isn't helping out,
this calls for a simple straightforward class IMHO (like the nested
fb:javascript/on-save and on-load code) and only if people think they
need the additional local-config then they should provide a factory
method that nows how to deal with that
at that moment I think jxpath and/or avalon dependencies are just over
the top for the binding-problem the user wants to solve?
wdot?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] Custom Binding.
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.03.2004 08:45, Marc Portier wrote:
> hm, if SoC is the argument, then shouldn't we consider the who is doing
> what discussion?
>
> my feeling is that touching the xconf is out of question to a lot of
> users? They could easily write up a custom-binding and be glad they
> never need to learn about the xconf in the first place?
I don't know if I follow this argumentation. Having configuration
splitted over multiple files might help the user at the beginning, but
can lead to a nightmare at the end. But maybe I just want to do anything
to perfect :)
Joerg
Re: [cforms] Custom Binding.
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> On 29.03.2004 16:06, 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
>>
>> 2/ Custom Binding Builder
>
>
> But isn't this just about moving the conf from cocoon.xconf to binding
> file (what I would not like for SoC reasons)?
>
hm, for the @builder case you have a point
but the @class case behaves different IMHO, and like Sylvain points out
releaves the pain of needing to write a builder
hm, if SoC is the argument, then shouldn't we consider the who is doing
what discussion?
my feeling is that touching the xconf is out of question to a lot of
users? They could easily write up a custom-binding and be glad they
never need to learn about the xconf in the first place?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] Custom Binding.
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.03.2004 16:06, 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
>
> 2/ Custom Binding Builder
But isn't this just about moving the conf from cocoon.xconf to binding
file (what I would not like for SoC reasons)?
Joerg
Re: [cforms] Custom Binding.
Posted by Marc Portier <mp...@outerthought.org>.
Tim Larson wrote:
> On Mon, Mar 29, 2004 at 04:06:40PM +0200, Marc Portier wrote:
>
>>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.
>
> <snip all the interesting stuff/>
>
> I hit a case where I wished I could use the javascript binding for a
> container widget (in this case a repeater) and then still be able to use
> the normal built-in java bindings for the contained widgets. Could you
> consider this usecase in your custom java binding hook design?
>
Tim,
I'm also writing up on the issue of repeater-binding as we speak...
The goal there is to write up a catalog of possible use cases for the
repeater-binding, pls check if your use case is not covered there.
In more general terms I hear you ask for custom-bindings to hook back
into predefined bindings, right
I'ld have to give that some more thought... proposals welcome of course...
maybe things could be so simple as requiring the @builder variant of the
<fb:custom> have a factory-method that takes both the nested DOM-config
and the 'Assistant'... hm, but that one is today a quite specific and
jxpath-tight thing IIRC, would need to see if we could abstract that out
in a sensible way
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] Custom Binding.
Posted by Tim Larson <ti...@keow.org>.
On Mon, Mar 29, 2004 at 04:06:40PM +0200, Marc Portier wrote:
> 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.
<snip all the interesting stuff/>
I hit a case where I wished I could use the javascript binding for a
container widget (in this case a repeater) and then still be able to use
the normal built-in java bindings for the contained widgets. Could you
consider this usecase in your custom java binding hook design?
--Tim Larson
Re: [cforms] Custom Binding.
Posted by Marc Portier <mp...@outerthought.org>.
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/
mpo@outerthought.org mpo@apache.org
Re: [cforms] Custom Binding.
Posted by Sylvain Wallez <sy...@apache.org>.
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.
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }