Re: Accessing Transformiix library from C++
Axel Hecht <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.layout.xslt |
|---|---|
| Organization | Another Netscape Collabra Server User |
| Message-ID | <[email protected]> |
Axel Hecht wrote:
> Allan Beaufour wrote:
>
>> Peter Van der Beken wrote:
>>
>>> Allan Beaufour wrote:
>>>
>>>> Axel Hecht wrote:
>>>>
>>>>> You can use DOM Level 3 XPath, esp nsIDOMXPathEvaluator, which is
>>>>> implemented by html and xml documents. See that interface and its
>>>>> friends over in mozilla/dom/public/idl/xpath
>>>>
>>>>
>>>>
>>>> I know. I am aware that I need to access it directly. I am already
>>>> using the "normal" and exposed API for other things.
>>>
>>>
>>>
>>> Why do you need the lexer specifically?
>>
>>
>>
>> I need two things:
>> 1) Get "dynamic function usage" in an expression
>>
>> That is, find out whether and expression has any functions in it that
>> would change the result from call to call, e.g. "now()".
>>
>> 2) Get all nodes that an expression depends on
>>
>> That is all nodes that influences the expression, not the node set
>> returned from an Evaluate(). I need to know that "thing[at=../other +
>> ../another]" depends on "../other" and "../another" (and "thing" of
>> course).
>>
>> The first one is fairly easy done with the lexer. The second one is
>> more tricky, and could probably be done more easily done by
>> instrumenting one or more evaluate()-functions?
>
>
> So, what you need is something like the stuff that Jonas implemented in
> his xpath optim patch. I wonder if you could go for a few simple kinds
> of dependencies / or-all-of-the-doc. And get that exported to XPCOM.
>
> Anyway, we should know how often you need this optimization, and for
> what. Right now, this looks like "it would be simple for me if we had
> this", but this should balance in total.
> These requirements smell like "check if I have to reevaluate if a doc
> changes". How often does that happen? And, is this a validation thing or
> do you need to display up-to-date results of an xpath expression only?
So Allan directed me a bit closer to what's required, and it seems to
boil down to this:
What XForms wants is a list of nodes that can have impact on the result
of an expression. It uses that to determine the order in which to
evaluate expressions, and to detect loops in those dependencies (which
throws an error).
Now the dependency for an expression like
"instance('orderform')/shipTo/firstName"
(http://www.w3.org/TR/xforms/slice7.html#fn-instance) adds the
instance('orderform'), all shipTos and all firstNames. Predicates make
this even more tricky. As you have to evaluate all the nodeset
expressions there, at least.
IIRC, changes to the instance DOM that would add new nodes to the
requirements are said to be recalculating the deps as well, so adding a
shipTo node, or adding a node that fulfills a predicate. I bet we should
have a list of those actions here.
Anyway, what we need to evaluate is the codesize impact of the
alternative methods, and their efficiency.
I see two main routes,
1. XForms uses an xpcom XPath component (like transformiix)
2. XForms ships its own XPath engine, and does not depend on external
code to implement the infrastructure.
The first one gives a smaller download size and is probably easier in
terms of bridging data between mozilla and the xpath engine, the second
one may be easier to adapt to the requirements of XForms.
Why would adaption be hard? Because of the codesize impact. That is
Firefox download size we're talking about here. So we should understand
what that means and how expensive that is. And then we need to think
about how performant.
Give rise to ways 1.a and 1.b.
1.a nsPIXPathXFormsFriend
This way, transformiix would implement interfaces that would compute the
data needed by XForms on its internal datastructures. This is likely
more code and more efficient than 1.b, and it's harder to maintain.
2.b expression inspection
This way, transformiix expression implement interfaces that allow one to
look at steps, predicates and all that, evaluate parts of them with
given contexts, all in xpcom. This is still quite a bit of code.
I'm really not too sure, which one I would prefer. If we could get
patches for both and make up our mind afterwards? Evil.
Axel