Re: Implementing XForms XPath extension functions in a Mozilla extension?

Aaron Reed wrote:
> Along the same lines as Allan but different.
> 
> XForms has XPath extension functions like avg(), instance(), etc.  So we 
> are in a pickle.  Not only do we need to figure out how to get XPath to 
> call into our extension when the expression evaluator runs, but our 
> extension work will need access to all of the utility classes.

I'm still hoping that we can somehow bridge that by helper classes 
implementing xpcom interfaces, I have no idea right now, how to deal 
with the expr result, though. Peter?

> If we do the work in XPath to allow for Allan's dependency node stuff 
> AND the work that I need to XPCOMify a lot of the stuff in XPath so that 
> it can work well with extensions, would Firefox take it?  Or would we be 
> better off taking the hit and shipping our own XPath (and forgo the hope 
> of ever making it into the main tree)?

Currently, the dependency tracking seems to be the bigger fish to fry. 
I'd still need a more detailed input on which dependencies we really 
need to track, but it seems like we need to catch a bunch of node 
values, which depend on a sequence of text nodes. Now there is a tricky 
issue with text nodes, as you don't necessarily have to change their 
value, but you can remove them and add new ones. That's a bit odd in how 
to watch modfication events and track those.
But really, keeping track of the node values alone would mean that we 
have to duplicate each and every evaluate() method in our xpath 
expression objects. Or something equivalently crufty, like an optional 
argument of a "node value observer" or something. Yikes.

Anyway, to evaluate the cost, we need a precise description, "this can 
be done in the lexer" doesn't cut it for me.

But yes, the more I see, the more I can imagine you forking an xpath 
engine of your own. As an xpath engine needs to be equipped to serve 
xforms to do this stuff, nothing else will need it. (Besides xul templates?)

Axel