cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <>
Subject Re: [RT] Woody/Cocoon Forms binding w/Xindice
Date Tue, 13 Jan 2004 09:07:47 GMT
Upayavira wrote:
> Upayavira wrote:
>> Guido Casper wrote:
>>> Upayavira wrote:
>>>> Marc Portier wrote:
>>>>> now, in this case backendX is cocoon (modifiable) sources, so I
>>>>> would guess some saveToSource/loadFromSource can be made quite
>>>>> generic and might very well be candidates for natural extension
>>>>> of the woody2.js
>>>> Yup. You've confirmed what I suspected. What I was (indirectly)
>>>> getting at, is that binding to a source goes a little further than
>>>> binding to DOM or bean, but remains very generic, and would be
>>>> delighted to see it in woody2.js.
>>>> If/when I get to doing my modifiable XMLDBSource, I'll try adding
>>>> this to woody2.js, unless you beat me to it!
>>> IIUC you can pretty much copy what's in loadDocument and
>>> saveDocument of binding_example.js These are already generic to any
>>> (modifiable) source.
>> Ah, great. I was going to look there. I've got the XMLDBSource coded,
>> and am testing at the mo, so that's my next port of call.
> Thinking about this - why not use the Javascript version of instanceof
> within form.load and to transparently detect the type of the
> object passed to it? Then, if the object is a source, it is read
> from/written to, otherwise it is handled as at present.
> This keeps the interface much the same, but adds some really useful
> functionality.
> What do you think?

To be honest, my first thought was, that this shouldn't go into
woody2.js at all.

The Woody binding framework (currently) just deals with binding the form
model to your domain model.

Binding the domain model to the backend is the job of another component
like an O/R mapper does for binding a bean to a database (I can
understand that people want to have a direct database binding as this
relieves the developer from building a bean just as an intermediate
store, but this does not count for DOM :-)

Having convienience functions is fine, but I would prefer (may be just a
matter of personal taste) not to have too much magic and have the
functions be called separately like in:

var document = loadDocument(documentURI);

Hope this makes sense

View raw message