cvs: pear /XML_XPath TODO
| From: | Daniel Allen | Date: | Thu, 06 Jun 2002 10:54:48 +0000 |
| Subject: | cvs: pear /XML_XPath TODO | ||
| Groups: | php.pear.cvs | ||
| Request: | Send a blank email to pear-cvs+get-4448@lists.php.net to get a copy of this message | ||
dallen Thu Jun 6 06:54:48 2002 EDT
Modified files:
/pear/XML_XPath TODO
Log:
updates
Index: pear/XML_XPath/TODO
diff -u pear/XML_XPath/TODO:1.3 pear/XML_XPath/TODO:1.4
--- pear/XML_XPath/TODO:1.3 Wed Jun 5 03:54:06 2002
+++ pear/XML_XPath/TODO Thu Jun 6 06:54:48 2002
@@ -27,13 +27,28 @@
usable in the class
[*] implement getElementsByTagName and getElementById since there are domxml functions
- now
+ now...return as getElementsByTagName as XML_XPath_result objects..getElementById
+ will be a move function
[*] considering doing substringData for attribute nodes...just seems to make sense
[*] in _quick_evaluate_init, make sure the pointer is not null, could happen coming
off of a results object
- [*] it would be better if getChildNodeByName() and getSiblingNodeByName() (not called that
- now, but should be called that) are result object generation functions...this way
- we can seperate the cache from getting mixed up in bad instances...word...
+ [@] functions for result object are now
+ next()
+ rewind()
+ end()
+ nextByNodeName()
+ nextByNodeType()
+
+ [@] added getNodePath() to get the xpath location of the current node
+
+ [@] when using next() on XML_XPath_result, it counts the first node the first time, so
+ it moves from off the stage to on the stage the first time, then it moves to the next
+ node after that
+
+ [@] relative xpath queries
+
+ [*] fix this stdClass hack we have to do to get the result object to work with non xpath
+ queries (in cases of using dom queries)