Upayavira wrote:
Tony Collen wrote:
Has anyone given thought to binding a Woody form to a Xindice document?
I'm starting to develop an app, and I'd like to explore various binding methods. Xindice seems like it would be useful for this sort of thing.
I can only agree. And Vadim has been very active on XIndice - it has been improving a lot recently, with Vadim releasing 1.1B3 just after Xmas.
As I understand Woody's binding, Woody binds to DOM. Xindice can return DOM documents, so it is eminently possible. But, you'd need to use your own Java to access your XIndice instance.
Better though would be to improve the XMLDBSource to implement ModifiableSource. That way, you can bind to it both ways, which would be really neat.
Hmmm. Actually, Tony, I think you might have helped me with one of my own sites. If I can use Woody binding to bind to a modifiable XMLDBSource, I don't need to write any of my own Java, which would be cool. I think I'll have a go at making XMLDBSource modifiable. (For now, you'll only be able to bind to a document, not to a document fragment).
I presume binding to a modifiable source is straight-forward?
It depends on what you call 'binding'
strictly speaking (technically) the woody-binding is about copying values between the form-instance and some object-model coming from some backend....
these object-models are pretty much passive data-structures (value objects) and through jxpath the binding supports for them being either Java-Bean-like or w3c-DOM-like
with 'passive' I mean they just cary data: set/get stuff, but do not do operations like connect to xindice...
I understand that from a user-standpoint the 'binding' through methods like form.save() is perceived as case closed/over and done with/data persisted... but that is not the case: data has just been copied over from the web-interaction-model (woody widgets) over to some persistance-ready-model
the persistance action is one you still need to do.
When using FlowScript it is really easy to add those recurring actions to the Form model...
(check woody2.js to see how that is built up already)
in your own script you could add some custom wrappers around the build-in save and load
Form.prototype.loadFromBackendX = function(args){
this.model = ....
//whatever needed to load dom from your backend using the argsthis.load(this.model); }
Form.prototype.saveToBackendX = function(args){
this.save(this.model);//whatever needed to persist the this.model back ... (this.model); }
after which you could replace the form.save(domModel) by some more direct: form.saveToBackEndX(whateverNeeded)
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
I would not do away with the existing save/load for the pletora of existing back-ends that don't have the 'source' concept attaching to it.
HTH, -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]
