Jan Hoskens wrote:
Hi,
I'm trying to use a simple repeater in my binding with an xml document. When saving my document I get the following error:
Exception trying to create xpath.... Factory is not set on the JXPathContext - cannot create path: ....
I did a bit of sniffing and found a reply on a chain of mails that stated: (mail from Sylvain in reply to Timothy Larson )
http://www.mail-archive.com/[EMAIL PROTECTED]/msg09163.html
<snip>
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;
}
</snip>
actually, since that discussion the functions of the above createBindingContext function have been added to the Binding implementation:
- adding automatically the DOMFactory when the back-end model is a W3C Dom Node
- setting lenient to true on top level binding and imlementing some default/inheritence scheme on all the bindings.
if you are
1/ using cvs-head,
2/ passing a W3C Dom Node in the loadFormFromModel or saveFormToModel methods of the binding
3/ have not set some lenient="false"
then you shouldn't see that error
if you do get it in those circumstances then be sure to provide some more detail on your setup and error
But I don't get how to do the same (as stated in the previous flowscript) in Apples. Where do I create the context and how do I add it? The form stuff in Apples is somewhat different than the flowscript, and hence I get a bit lost (not many docs on Apples, so always looking through the api). I use Apples because of the more complex flow I have. (eg locking of files, checking on timestamps, selecting pipelines based on datasource attributes...) I'm hoping that I'm in the right direction with my choice of flow...(any comments on why to choose flowscript or another flow would be interesting here;-)
well, I'm the culprit for both having Apples (and having it without documentation, but you'ld have to admit the API (and even full code base) is little enough to hope that the available JavaDoc is just explanation enough, no?)
Looking back at Apples today I'ld have to admit it has pretty much been part of some transition I (and all of us hard core java peeps?) need to get through to learn and appreciate flowscript...
Having said that I still think its future can be a lot more then just an alternative guide to a better understanding of flowScript! IMHO what flowScript still lacks is a more solidified pattern (and possibly API) providing an optimal split between the roles of JavaScript and Java inside your controlling logic.
Today there is nothing more then some vague consensus that JavaScript should describe the pure flow (if, switch, while constructs) and delegating the actual processing to Atomic Avalon Services (in Java).
So today a logic/possible evolution of Apples might just very well be to become those Service Components. That could somewhat solidify how flowscript calls Java Services, with the added value that you could even call those directly from the sitemap (as done in todays Apples examples)
Rethinking the history of Apples, that would really be aligning completely with the original drive and reasoning: http://wiki.cocoondev.org/Wiki.jsp?page=GeneralizedFlow
But I am doubthing if the win is big enough to mobilise some effort around this. (other opinions?)
And taking up your example to explain what I'm saying here: when you say:
I use Apples because of the more complex flow I have.
then that really conflicts with your examples:
(eg locking of files, checking on timestamps, selecting pipelines based on datasource attributes...)
which are all 'services' and 'features', not programming-flow constructs
your analysis not to write those services and features in JavaScript is correct IMHO, but you should understand that you could achieve this by bundling those in Avalon Services and just *call* them from the flow.
as explained above the real flow-aspect is in the use of if/else, while, for() and the like.. to benefit from the pleasures of continuations you need to write those down in JavaScript.
The bonus of those continuations then comes at very little expense since those constructs are totally equivalent in both languages, no?
HTH, regards, -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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
