Remove XPath engine in XForms, and use Transformiix instead

RESOLVED WONTFIX

Status

Core Graveyard
XForms
--
enhancement
RESOLVED WONTFIX
13 years ago
10 months ago

People

(Reporter: Allan Beaufour, Unassigned)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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.
(Reporter)

Updated

13 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 1

13 years ago
(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

13 years ago
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.
(Reporter)

Comment 3

13 years ago
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.
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?
(Reporter)

Comment 5

13 years ago
(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.
Depends on: 208172
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.
(Reporter)

Updated

12 years ago
Blocks: 302168

Updated

11 years ago
Blocks: 326372

Updated

11 years ago
Blocks: 326373
(Reporter)

Updated

11 years ago
Severity: normal → enhancement

Comment 7

11 years ago
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.
(Reporter)

Comment 8

11 years ago
(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".
(Reporter)

Comment 9

11 years ago
(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.
Summary: Integrate XForms XPath functionality in Transformiix → Remove XPath engine in XForms, and use Transformiix instead
(Reporter)

Updated

11 years ago
No longer blocks: 326372
(Reporter)

Updated

10 years ago
Assignee: allan → xforms
Status: ASSIGNED → NEW
RIP xforms
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.