cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [Woody] observations, issues, questions, best practices
Date Mon, 19 Jan 2004 17:14:42 GMT


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/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message