lode leroy wrote:
Can anyone give some feedback on the status of the code inside src/dom ? How much works is still to be done to have xpath support working? I noticed that xpathimpl.cpp is actually just a stub, so I suppose that there's some work left to do... is anyone working on this?
-- lode
Yes, it is definitely a work in progress. I am working on the xpath stuff right now. xpathimpl will not get much more code, as it will merely be a wrapper of the parser(mostly done) and executor(working on it now). I have a few more files to check in after the freeze, which I typed up in a hotel room while running away from Hurricane Rita, which are the start of an xpath tokenization class and an evaluation stack.
I am implementing it in a retained mode, where the xpath strings are all "compiled" to strings of tokens, which are later executed on an evaluation stack. This extra step will speed up execution considerably over immediate mode, where the string would be interpreted every time it is encountered. For example, if one wrote this bit of code in Javascript to animate an svg object with the ID of DrunkenCat:
for (int i=100 ; i<200 ; i+= 20) { xpath.assign("document.svg.DrunkenCat.x", i); } We would compile the ref once, but resolve the node dynamically, in case the dom structure is changing. A string cannot be resolved to a NodeList at the start, as we must assume that the dom tree can be changing dynamically beneath xpath.
I have written such a compile/execute structure several times in the past for rule-based projects, so this is familiar territory to me, and I am aware of what to implement and what to avoid.
Yes, xpath will definitely be completed in this cycle. Casting Inkscape internals as org::w3c::dom::Nodes would be pointless until we can use xpath to be able to expose them to the outside world via script.
Bob