XPathGenerator: alternate approaches?
Alex Vincent
XPathGenerator API and design. Right now, I'm not seeing any objections
to dropping support for attributes, including in my own usage. So it's
very likely that any next patch I submit will drop support for that, and
the wiki page will be updated to reflect that.
In terms of writing the component in JavaScript: I'd love to if I
could. The problem is how to write it so people won't have to load any
specific scripts, and can still do "var gen = new XPathGenerator()".
According to jst, it's simply not possible for a JS component to create
a constructor like this (DOMClassInfo issues)
Which brings up some other design approaches, and I'd like to discuss them.
(1) We can add global objects (not constructors, but objects) by using
the category manager and a category of "JavaScript global property".
This might mean a global object which has a method to create generators,
or more likely a single generator itself which is shared across the
application like a service.
The only drawback to this approach I can think of is the namespace
resolver might end up shared as well, and thus
filled with namespaces from other users. It'd be simple to fix if that
was a problem, though, by replacing the resolver property of
nsIXPathGenerator with a createResolver() method, and then requiring a
nsIXPathGeneratorResolver argument with generateXPath().
(2) We could find some way for the C++ module in nsXPathGeneratorModule
to return a JS-based component.
(3) The C++-based component could simply be a wrapper for a JS-based
component, forwarding all calls to the JS component.
I really dislike these two ideas, as they sound like using a hammer to
tighten a nut.
(4) We fix the underlying issue which prevents JS-based components from
adding constructors to the global object.
Although as a concept I like this idea, it becomes hard to justify based
on an apparent lack of demand. (i.e. I'm not aware of anyone asking for
it before). I initially thought this might be a matter of simply
documenting the DOMCI macros and how to write them in JS, but I'm told
it's simply not possible right now.
(5) ???
Alex Vincent
Santa Cruz, CA
Jonas Sicking
I had a conversation with jst and myk about this.
First off it feels like the right thing to axe attribute filters for
now. I actually think that myk might be onto something about it's more
useful to filter on node contents rather than node attributes. This
especially since it's much easier to create UI for the user to choose a
specific contents, rather than attribute values. However I think we
should wait with adding such ability to after the initial checkin is done.
Second, it would be a good idea to write this in JS. Solving the issue
with global constructors for JS components is something we should do
anyway, your component is not the only one needing it. Especially going
forward.
The issue here is more how to do it for now. Either you could simply
wait with checking this stuff in until we have code that enables this.
What is you time plan for a JS component?
Alternatively you could write some C++ glue specifically for your
component for now and we'd change that once we add a proper API for js
components.
Such a C++ wrapper would not need wrap the actual XPathGenerator object.
You would only need to add a small amount of code that registers the
global constructor. Once the constructor is invoked you can simply
return the JS object (created through XPCOM).
I'm really sorry for the back'n'forth of the js-ness of the
XPathGenerator. We should make sure to talk this through more thoroughly
before you start whacking at the code to convert it to js.
/ Jonas
Alex Vincent
> The issue here is more how to do it for now. Either you could simply
> wait with checking this stuff in until we have code that enables this.
> What is you time plan for a JS component?
I figure it would take me less than a week to do the necessary
conversions. I'm really pushing to get XPathGenerator, in one form or
another, checked in for Gecko 1.9 and preferably on by default. I'm
running out of time on that front -- especially given review cycles.
There would be no significant changes to the IDL, and I have written a
JS-based approach once before (sadly, I don't have the original files
anymore).
> Alternatively you could write some C++ glue specifically for your
> component for now and we'd change that once we add a proper API for js
> components.
>
> Such a C++ wrapper would not need wrap the actual XPathGenerator object.
> You would only need to add a small amount of code that registers the
> global constructor. Once the constructor is invoked you can simply
> return the JS object (created through XPCOM).
I need a little help to figure that out. The module code is confusing
enough.
Alex