MozillaWiki

DOM/XPath Generator: Difference between revisions

Page Discussion

DOM/XPath Generator (view source)

Revision as of 01:55, 12 May 2015

2,692 bytes added ,  12 May 2015
m
GPHemsley moved page DOM:XPath Generator to DOM/XPath Generator without leaving a redirect
(Removed the viewPartionSource usecase since it would have no use for this)
m (GPHemsley moved page DOM:XPath Generator to DOM/XPath Generator without leaving a redirect)
 
(13 intermediate revisions by 4 users not shown)
Line 39: Line 39:
namespace resolver (assuming that we need to handle XML to be future proof)." -- Alex Hecht
namespace resolver (assuming that we need to handle XML to be future proof)." -- Alex Hecht


[http://verbosio.mozdev.org Verbosio] would be able to translate a XPath for a document it's editing into a XPath for a XUL tree (a la DOM Inspector) representing the document's structure.  This would be through simple text replaces.  Thus, a node found in the master document would easily translate to a XUL tree item.
[http://verbosio.mozdev.org Verbosio] would be able to translate a XPath for a document it's editing into a XPath for a XUL tree (a la DOM Inspector) representing the document's structure.  This would be through simple text replacements.  Thus, a node found in the master document would easily translate to a XUL tree item.


Shane Caraveo at ActiveState is working to develop a XUL unit test extension that would work in a similar fashion to Selenium and Selenium Recorder.  This consists of recording DOM events, and saving an xpath to the event target so the target can found and used to replay an event.  Exploratory code is in [https://bugzilla.mozilla.org/show_bug.cgi?id=323938 bug 323938].
Shane Caraveo at ActiveState is working to develop a XUL unit test extension that would work in a similar fashion to Selenium and Selenium Recorder.  This consists of recording DOM events, and saving an xpath to the event target so the target can found and used to replay an event.  Exploratory code is in [https://bugzilla.mozilla.org/show_bug.cgi?id=323938 bug 323938].
Line 48: Line 48:


<pre>
<pre>
#include "domstubs.idl"
#include "domstubs.idl"
#include "nsIDOMXPathNSResolver.idl"


[scriptable, uuid(ab50beb3-4049-4299-92ea-4dea4609a1e1)]
[scriptable, uuid(341d8cbe-bcb3-4d9a-a5a6-dd4ef72a402d)]
interface nsIXPathGenerator : nsISupports {
interface nsIXPathGenerator : nsISupports {
   /* A collection of bitwise flags which modify behavior.
   /* A collection of bitwise flags which modify behavior.
Line 57: Line 57:
   */
   */


   // Ignore ID-type attribute nodes on elements and continue to the document node.
   // Ignore ID-type attribute nodes on elements and continue to the document or context node.
   const unsigned long GO_TO_DOCUMENT_ROOT          = 0x00000001;
   const unsigned long GO_TO_DOCUMENT_ROOT          = 0x00000001;
  // Return expression containing a single step that uses the descendant axis.
  const unsigned long USE_DESCENDANT_AXIS          = 0x00000002;


   /**
   /**
   * Flags which modify the parameters used to generate the xpath string.
   * Flags which modify the parameters used to generate the xpath string.
   */
   */
   unsigned long attribute searchFlags;
   attribute unsigned long searchFlags;


   /**
   /**
Line 93: Line 96:
   * Namespace resolver corresponding to all generated xpaths.
   * Namespace resolver corresponding to all generated xpaths.
   */
   */
   readonly nsIDOMXPathNSResolver resolver;
   readonly attribute nsIDOMXPathNSResolver resolver;


   /**
   /**
   * Generate the xpath as a string.
  * Add a namespace URI and prefix to the namespace resolver.
  *
  * @param namespaceURI    The namespace URI of the namespace.
  * @param prefix          The prefix of the namespace.
  */
  void addNamespace(in DOMString namespaceURI,
                    in DOMString prefix);
 
  /**
   * Generate a xpath as a string.
   *
   *
   * @param targetNode  The node our xpath ends at.
   * @param targetNode  The node our xpath ends at.
Line 103: Line 115:
   * @return DOMString XPath from the context node to the target node.
   * @return DOMString XPath from the context node to the target node.
   */
   */
   DOMString generateXPath(in nsIDOMNode targetNode
   DOMString generateXPath(in nsIDOMNode targetNode,
                           in nsIDOMNode contextNode);
                           in nsIDOMNode contextNode);


Line 114: Line 126:
   * @return DOMString XPointer from the context node to the target node.
   * @return DOMString XPointer from the context node to the target node.
   */
   */
   DOMString generateXPointer(in nsIDOMNode targetNode
   DOMString generateXPointer(in nsIDOMNode targetNode,
                             in nsIDOMNode contextNode);
                             in nsIDOMNode contextNode);
 
};
}
</pre>
</pre>


Line 132: Line 143:


I think we should add a generateXPointer function too, since it's trivial to implement once we have implemented generateXPath and the resolver. You just need to serialize the namespace mappings from the resolver following the [http://www.w3.org/TR/xptr-xmlns/ XPointer xmlns() scheme] and use the [http://www.w3.org/TR/xptr-xpointer/ XPointer xpointer() scheme] for the result of generateXPath. -- Peter Van der Beken
I think we should add a generateXPointer function too, since it's trivial to implement once we have implemented generateXPath and the resolver. You just need to serialize the namespace mappings from the resolver following the [http://www.w3.org/TR/xptr-xmlns/ XPointer xmlns() scheme] and use the [http://www.w3.org/TR/xptr-xpointer/ XPointer xpointer() scheme] for the result of generateXPath. -- Peter Van der Beken
It would probably be a good idea to include a addNamespace(namespaceURI, prefix) method to the IDL, to point into the resolver's namespace map. -- Alex Vincent
I'd like the ability for a caller to tell the generator that it should identify the starting node by the content it contains when calling generateXPath.  We could do that by adding a searchFlag called something like IDENTIFY_START_BY_CONTENT which triggers the behavior.
When I say "identify the starting node by the content it contains", I mean use the contains() method or the like to filter nodes with the same tag name.  For example, for an XPath expression starting at a DIV node whose content is "foo", the beginning of the XPath expression should be DIV[contains(.,"foo")] or some other XPath construct which identifies the node by the content it contains. -- Myk Melez
== XPath: Content Boundaries ==
(non-normative)
Mozilla's XPath implementation doesn't currently support crossing boundaries between framed content and the container frame element, or between real content and its anonymous children.  Our XPath and XPathGenerator can be reasonably expected to support this in the future, so now's the best time to come up with a function syntax for doing this.
Suggested new XPath functions:
* From element in framed document to the container iframe:
** XPath 1: "frameElement(.)" (Alex Vincent)
** XPath 2: "./frameElement()" (Alex Vincent)
* From container iframe to element in the framed document:
** XPath 1: "contentDocument(.)" (Alex Vincent)
** XPath 2: "./contentDocument()" (Alex Vincent)
* From anonymous content to the XBL-bound parent:
** XPath 1: "bindingParent(.)" (Alex Vincent)
** XPath 2: "./bindingParent()" (Alex Vincent)
* From XBL-bound parent to first anonymous child:
** XPath 1: "anonymousChild(.)[1]" (Alex Vincent)
** XPath 2: "./anonymousChild()[1]" (Alex Vincent)
<pre><sicking> we do not want a different syntax in xpath2
<sicking> at least i think not. at the very least we do not want to commit to it</pre>
Whatever you think is a better syntax, please suggest it here.  All suggestions are welcome.
Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=326745 bug 326745]
GPHemsley
canmove, Confirmed users, Bureaucrats and Sysops emeriti
960

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/16473...1074006"