265212 - Remove XPath engine in XForms, and use Transformiix instead

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, enhancement)

Description

[Allan Beaufour]

Ee have a lot of code in the XForms code (extensions/xforms/nsXFormsXPath*) that
is used to find node dependecies in XPath expressions. For the moment it is not
dependent on any existing XPath functionalities in Mozilla. This should be in
incorporated in the Transformiix code.

Comment 1

[Allan Beaufour]

(In reply to comment #0)
> Ee have a lot of code in the XForms code (extensions/xforms/nsXFormsXPath*) that
> is used to find node dependecies in XPath expressions. For the moment it is not
> dependent on any existing XPath functionalities in Mozilla. This should be in
> incorporated in the Transformiix code.

The question is the how and where we should incorporate this? Any suggestions?

Comment 2

[Leigh L. Klotz, Jr.]

There are some special cases in XPath expression dependency analyzer: in certain
cases, self-references should be ignored rather than causing errors.  In moving
the analyzer out, this requirement should be taken into account.

Comment 3

[Allan Beaufour]

You mean 4.3.6, 4. in the spec. I guess? In fact I wasn't aware of that little
detail, thanks for mentioning it.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Once bug 208172 gets checked in we should have some way of walking over a parsed
xpath expression and get whatever information is needed.

I take it that there are two things that you guys need: The ability to check
that the xpath expression follows the various constraints that the xforms spec
puts on xpath expressions, and getting information to build the dependency
graph. Or do you guys need to modify the expression too?

Comment 5

[Allan Beaufour]

(In reply to comment #4)
> Once bug 208172 gets checked in we should have some way of walking over a parsed
> xpath expression and get whatever information is needed.

Ah. I had forgotten about that one. peterv mentioned that, a long time ago.
 
> I take it that there are two things that you guys need: The ability to check
> that the xpath expression follows the various constraints that the xforms spec
> puts on xpath expressions, and getting information to build the dependency
> graph.

This bug needs the last part, yes. For that we also need to be able to either
extract portions of the expression and/or evaluate them.

> Or do you guys need to modify the expression too?

Not as far as I know. But we need to set the context size and position when
evaluating an expression.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So here's what I think we should do:

Create a 'parsed tree analyzer' with an interface like this:

interface nsIXPathExpressionAnalyzer : nsISupports
{
  const unsigned long OTHER = 0;
  const unsigned long PATH_EXPR = 1;
  const unsigned long STEP_EXPR = 2;
  const unsigned long FUNCTIONCALL_EXPR = 3;
  const unsigned long LITERAL_EXPR = 4;
  const unsigned long ELEMENTNAME_NODETEST = 5;
  const unsigned long ATTRIBUTENAME_NODETEST = 6;
  const unsigned long NODETYPE_NODETEST = 7;
  // we can add/remove here as we need

  void init(nsIDOMXPathExpression);

  boolean goToChild(in unsigned long index);
  boolean goToParent();

  unsigned long getType();
  AString getName();
  boolean isPredicate();   // we might not need this one
};

This is just a draft!

We might need more or fewer types. And more or fewer functions like getName().
It's somewhat a matter of whether we want to make the interface generic or just
enough to fit xforms needs.

The goToXXX functions returns false if there is no such child/parent. An
alternative to goToChild is goToFirstChild+goToNextSibling, it's mostly a matter
of putting some effort on the implementation or the user.

Comment 7

[Axel Hecht]

Just to clarify this, are we talking about hooks providing xpath expression
inspection, or are we talking about shipping parts of XForms with the Mozilla
toolkit?

Regarding the interface, returning bools for goTo success/failure of that method
looks so non-DOMish. It may not be harder from a coding point of view to just
get objects for the children and parent.

Comment 8

[Allan Beaufour]

(In reply to comment #7)
> Just to clarify this, are we talking about hooks providing xpath expression
> inspection, or are we talking about shipping parts of XForms with the Mozilla
> toolkit?

Hooks providing XPath expression inspectiong. I'm biased of course :), but I do not think we (XForms) would be the only consumers of getting "node dependencies on XPath expressions".

Comment 9

[Allan Beaufour]

(In reply to comment #8)
> (In reply to comment #7)
> > Just to clarify this, are we talking about hooks providing xpath expression
> > inspection, or are we talking about shipping parts of XForms with the Mozilla
> > toolkit?
> 
> Hooks providing XPath expression inspectiong. I'm biased of course :), but I do
> not think we (XForms) would be the only consumers of getting "node dependencies
> on XPath expressions".

Pike suggested that I changed the summary, good point :)

I'm not sure what we actually depend on in xslt/-land now? We need a walker or a way to get dependencies for a given expression.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms