Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
<snip />
I was attempting and failing to bind to an XML document. The load worked, but the save gave the exception.
Sylvain?
I know Sylvain created this:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/util/jxpath/DOMFactory.java
exactly to cater for the automatic creation (factory) of DOMNodes triggered from jxpath createPath statements...
But I have to admit I can't find where that thingy gets registered on the jxpath context (too much relying on the advanced search of eclipse?)
Sorry, I'm very late on all this.
Actually, there's currently no use of this class in Cocoon samples, but I use it on my projects. Here's how: in the flow, I don't load/save the DOM directly, but through a JXPathContext as follows;
var doc = readDocument(url); var bindingCtx = createBindingContext(doc); form.load(bindingCtx); form.showForm("pipeline"); form.save(bindingCtx);
And here's the createBindingContext function:
function createBindingContext(document) {
// Create a JXPath context on the document.
var xpathContext = Packages.org.apache.commons.jxpath.JXPathContext.newContext(document);
// Set it to lenient
xpathContext.setLenient(true);
// Add the necessary factory create elements and attributes as needed on non-existing paths
xpathContext.setFactory(new Packages.org.apache.cocoon.util.jxpath.DOMFactory());
return xpathContext;
}
Thx for explaining!
Having to explain how this work yesterday during a training, I felt that it should be better hidden in the binding machinery, since this is somehow needed every time we bind a form do a DOM (unless the DOM already contains the whole XML structure).
So what about adding this into the AbstractJXPathBinding: if the object passed to load/save is a Node, then add the DOMFactory automatically.
Makes sense! (that is were I was looking for the registration in the first place :-))
Only thing to look out for is the possible combination with the insert-node binding? (haven't checked yet how jxpath handles multiple registries)
We may create a child JXPathContext in InsertNodeJXPathBinding to avoid overriding the DOMFactory, but I'm wondering if using a factory is needed at all in InsertNode: isn't a simple "appendChild" enough?
i.e. Node node = (Node)jxPathContext.getContextPointer().getNode().appendChild(toInsert)
that is what the factory is doing :-) but I catch your drift: the detour is not really needed...
in any case: I'll have a special look at this when I make the changes
On a side-note: isn't the utility class a more natural addition to jxpath (in the long run?)
Sure, we may contribute it. But there's still a problem that needs to be fixed, which is that it fails to create an attribute whose owner element doesn't exist.
fine, was just a thought popping up, thx for explaining
And finally: I'm taking it you are quite ok with the rest of the proposal? (just wanted to check)
Basically, I'm ok with having the two kinds of binding sharing a similar syntax (on-bind, on-insert, etc), but I'm not sure merging them in a single binding is a good idea, as apart "row-path" and "parent-path", their other attributes are very, very different.
yep, that is the exercise ahead of us: find an optimal way to do it, as you can see from the mails, my own vision is still shifting...
So I would better be in favor of some more explicit names such as "delta-repeater" for "repeater" and "override-repeater" for "simple-repeater".
WDYT?
I'm still closer to the strategy attribute idea, but I definately agree it could be separated classes.... (shared stuff common, different stuff separated?)
IMHO having separate elements confuses people more then having a strategy-selecting attribute, but that might be just an impression?
maybe odd, but a side-effect of the attribute thingy will be that the alternatives are more naturally documented together...
I like the name delta-repeater more then my own proposal of diff-repeater, but simple and override score less then the rebuild-repeater?
more opinions? -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]
