Last Comment Bug 265212 - Remove XPath engine in XForms, and use Transformiix instead
: Remove XPath engine in XForms, and use Transformiix instead
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: XForms (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: xforms
: Stephen Pride
Mentors:
Depends on: optim_xpath
Blocks: 302168 326373
  Show dependency treegraph
 
Reported: 2004-10-20 04:11 PDT by Allan Beaufour
Modified: 2016-02-04 12:20 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Allan Beaufour 2004-10-20 04:11:21 PDT
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 2004-10-20 04:14:04 PDT
(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. 2004-11-08 13:09:54 PST
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 2004-11-09 00:31:41 PST
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) PTO Until July 5th 2005-01-13 04:02:36 PST
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 2005-01-13 04:11:36 PST
(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) PTO Until July 5th 2005-01-13 07:39:58 PST
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 2006-04-21 03:26:18 PDT
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 2006-04-21 03:35:59 PDT
(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 2006-04-21 04:00:44 PDT
(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] 2016-02-04 12:20:06 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.