cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Woody/Cocoon Forms binding w/Xindice
Date Wed, 14 Jan 2004 09:15:14 GMT


Guido Casper wrote:

> 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 form.save 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);
> form.load(document);
> form.showForm("form-display-pipeline");
> form.save(document);
> saveDocument(document,documentURI);
> 
> Hope this makes sense

it does, and I resonate a lot: big +1 to avoid magic

also having the saveDocument and loadDocument you propose here _outside_ 
the woody specific flowscript seems to make them more widely re-useable 
in different areas!

with those in place I think my previous idea to 'extend' the Form object 
from woody2.js is a nice (almost trivial) example left to the reader 
(meaning that if that gets into cvs it should probably be in some 
'samples' directory)

wdyt?
-marc=

> Guido
> 
> 

-- 
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


Mime
View raw message