Joerg Heinicke wrote:
Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:


4. The switching of binding to XML or beans costs to much effort. Binding file, JXTemplate (for the result), flow script. Maybe I did something the wrong way, but the XML needs at least a root element, why this would be annoying for the bean. Some ideas for that?

hm, both are supported, but that doesn't necesarrily mean that swapping between both is that easy.


I encountered the same when doing the first of my binding-samples... I ended up switching easily by not passing the DOM directly into the binding, but rather the root-node. Note: when binding to XML you need to pass in a DOM Node, not a DOM Document!

Sometimes it's soo simple. But could it be that it is a one-way ticket?

nope works both ways for me, of course I write back to the same document I read fromm



Saving the "document" back does not work, because document is null.

howcome?

Good question. I simply used the woody2.js and the loadDocument() and saveDocument() from binding.js. Hmm, I will look again.


I investigated the problem a bit more and my first observations were wrong. Not
the document is null, but it's value. I guess that's ok, as toString() probably
returns the text nodes. So it look like "[data: null]" when <data> is the
document element.

The real problem now is to save this thing back to file. If I pass the document
element only to saveDocument() I get an empty file. If I pass the root node (the
one above document element - how is it correctly called in DOM?) I get the file
as expected. But it seems not to be possible to get from document element to
root node. I tried ownerDocument() and get following exception:

"uncaught JavaScript exception: TypeError: [#document: null] is not a function."


isn't the full name getOwnerDocument()?


This has nothing to do with the immediate steps of loading and saving the model
as also a document.getDocumentElement().ownerDocument() in loadDocument() (where
I expect document again) results in the exception above. How did you save the
document back, Marc? Or do you or anybody else know why ownerDocument() fails?

euh, as you can see in the binding samples I didn't :-)



Joerg



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



Reply via email to