phpxpath-users Mailing List for Php.XPath (Page 9)
Brought to you by:
bs_php,
nigelswinson
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(346) |
Nov
(8) |
Dec
(21) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(30) |
Feb
(13) |
Mar
|
Apr
(3) |
May
(70) |
Jun
(26) |
Jul
(48) |
Aug
(22) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
2003 |
Jan
(3) |
Feb
(3) |
Mar
(11) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2004 |
Jan
(4) |
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
(12) |
Aug
(8) |
Sep
(2) |
Oct
(2) |
Nov
(3) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2006 |
Jan
(3) |
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Nigel S. <nig...@us...> - 2002-05-24 02:04:20
|
> > Sounds like you know what you are talking about. Looking forward to seeing > > your patch ;o) > > ok, I will try and get this done (and tested!) next week. What's easiest for > you - an actual patch (i.e. snippets of code) for you/whoever to edit in, or > a complete new class file? A complete new class file would probably be easiest... can't be bothered learning how to use the patch tool. Please alter from the most recent version from CVS though (and tell us which version it was you took) so that it's clear what changes you made. Also if it makes sense, writing some tests would be good and we could add them to the testHarness. Not sure how convenient /complex/worthwhile it would be to have much in the way of tests for this feature though... Thanks :o) Nigel =========================== For the most recent version of Php.XPath, and an archive of this list visit: http://www.sourceforge.net/projects/phpxpath |
From: Peter R. <php...@pe...> - 2002-05-23 14:56:50
|
that's not true, Dan. If it were, none of my scripts would work! Currently, all my xml files are in 8859-1 (though I will have to change to utf8 to allow for Czech characters) and all the accented characters are in 'regular form' as you call it. None of my php scripts, including phpxpath, has any problems handling this. If by entities you mean things like ä these are html entities and nothing to do with xml (except in the limited case of xhtml). In some ways it's a pity php (and utf8_encode) only handles 8859-1, but at the end of the day unicode/utf8 is a far superior model, so longer-term it's better to convert everything over anyway. On Friday 17 May 2002 9:58 pm, Dan Allen wrote: > Just so everyone knows, xml requires that us use UTF-8 encoding in > your xml documents. That means it is impossible to have all of > those german/french accents in regular form. You must use XML > entities, which just like < and > replace in the output those > characters which are not alpha-numeric characters. So the phpxpath > code should not! check for these characters, you should convert them > when you make your document by using > utf8_encode() |
From: Sam B. <bs...@us...> - 2002-05-23 09:53:38
|
Hi Peter , Always's happy to have new ppl on board giving us a hand! ;o) You seam to have some trouble with the Entity handling in Php.XPath. I'm not quite sure if I understand the problem. But pleas read following extract taken from Php.XPath's _translateAmpersand () function. I think it's a good base to undersand the problematic. /** * Translate all ampersands to it's literal entities '&' and back. * * I wasn't aware of this problem at first but it's important to understand why we do this. * At first you must know: * a) PHP's XML parser *translates* all entities to the equivalent char E.g. < is returned as '<' * b) PHP's XML parser (in V 4.1.0) has problems with most *literal* entities! The only one's that are * recognized are &, < > and ". *ALL* others (like © a.s.o.) cause an * XML_ERROR_UNDEFINED_ENTITY error. I reported this as bug at http://bugs.php.net/bug.php?id=15092 * (It turned out not to be a 'real' bug, but one of those nice W3C-spec things). * * Forget position b) now. It's just for info. Because the way we will solve a) will also solve b) too. * * THE PROBLEM * To understand the problem, here a sample: * Given is the following XML: "<AAA> < > </AAA>" * Try to parse it and PHP's XML parser will fail with a XML_ERROR_UNDEFINED_ENTITY becaus of * the unknown litteral-entity ' '. (The numeric equivalent ' ' would work though). * Next try is to use the numeric equivalent 160 for ' ', thus "<AAA> <   > </AAA>" * The data we receive in the tag <AAA> is " < > ". So we get the *translated entities* and * NOT the 3 entities <   >. Thus, we will not even notice that there were entities at all! * In *most* cases we're not able to tell if the data was given as entity or as 'normal' char. * E.g. When receiving a quote or a single space were not able to tell if it was given as 'normal' char * or as or ". Thus we loose the entity-information of the XML-data! * * THE SOLUTION * The better solution is to keep the data 'as is' by replacing the '&' before parsing begins. * E.g. Taking the original input from above, this would result in "<AAA> &lt; &nbsp; &gt; </AAA>" * The data we receive now for the tag <AAA> is " < > ". and that's what we want. * * The bad thing is, that a global replace will also replace data in section that are NOT translated by the * PHP XML-parser. That is comments (<!-- -->), IP-sections (stuff between <? ? >) and CDATA-block too. * So all data comming from those sections must be reversed. This is done during the XML parse phase. * So: * a) Replacement of all '&' in the XML-source. * b) All data that is not char-data or in CDATA-block have to be reversed during the XML-parse phase. * */ -- Sam Blum <bs...@us...> =========================== For the most recent version of PHP.XPath and an archive of this list visit: http://sourceforge.net/projects/phpxpath |
From: Peter R. <php...@pe...> - 2002-05-23 09:39:57
|
what context/baseXPath does this new feature of being able to use an XPathquery in say getData use? Does it always use the evaluate default, i.e. the root node? If so, you should be able to check on presence of / or [ If present, then it's a query, if not, it's a nodename. (er, I think, or am I getting confused? :-) I think we need to move away from the concept of locale/charset. If you're using ucs, a file, or for that matter node, can contain characters from any number of different languages/locales, and has nothing to do with what locale the machine/operating system works under. On Tuesday 21 May 2002 11:06 pm, Nigel Swinson wrote: > > There is no such limitation. In that line we are purely trying to work out > if the $nodeTest is JUST a node name, or whether it is an XPath Expression. > > My suggestion is that we change to: > > elseif (preg_match('/^[\w\-]+$/', $nodeTest)) { > > The PHP manual says \w is a word character where a word character is > defined as: > > ============= > A "word" character is any letter or digit or the underscore character, that > is, any character which can be part of a Perl "word". The definition of > letters and digits is controlled by PCRE's character tables, and may vary > if locale-specific matching is taking place (see "Locale support" above). > For example, in the "fr" (French) locale, some char- acter codes greater > than 128 are used for accented letters, and these are matched by \w. |
From: Peter R. <php...@pe...> - 2002-05-23 09:09:49
|
doesn't seem to work any more. Looking through the class, it looks like the problem is to do with the translateAmpersand function, though I tried disabling this function and that didn't fix the problem, so there must be more to it. The documentation for this seems to be saying that the parser should be prevented from, er, parsing, which seems odd to me - if you don't want entities parsed, why use them? - but if this is necessary, can it be made switchable please: yes I want entities parsed, or no I don't. I don't use entities extensively but they are a modestly useful function. |
From: Peter R. <php...@pe...> - 2002-05-23 08:39:12
|
On Wednesday 22 May 2002 12:20 am, Nigel Swinson wrote: > > > > see xml_parser_create > > add parameter to this statement (in, erm, importFromString), and then > there > > would have to be some way of setting it to utf-8 or us-ascii (in case > anyone > > actually uses that). Because you can pass the constructor the filename, > you > > would have to pass this in as a param. Or of course not allow it here, > > but only with importFromString, and have a separate function to set > > before calling that. > > Sounds like you know what you are talking about. Looking forward to seeing > your patch ;o) ok, I will try and get this done (and tested!) next week. What's easiest for you - an actual patch (i.e. snippets of code) for you/whoever to edit in, or a complete new class file? |
From: Nigel S. <nig...@us...> - 2002-05-21 23:18:22
|
> > > hm, I can see that being able to update all the nodes in a set with one > > > instruction is useful, but why getDataParts and not any of the other get > > > functions? > > > > getData() calls getDataParts(), so getData() takes a xPathQuery. Have > > updated the source... Which other "get" functions are missing this? > > I was using your list, Nigel. getDataParts was the only one of the retrieval > functions on it. Ok, and which other get functions do you want xPathQuery access to? Perhaps there are reasons, but at the moment there doesn't seem to be a concrete example for me to comment on, and I'm too busy/lazy to research it. All I have to go on is "any of the other get functions". > > > On a related issue, could you add the ability to set the source encoding. > > > > Ummm I don't really know where to start in coding this feature, as I don't > > really understand what's required. It does sound like a useful addition > > though, as I know we have many european users. It's not an issue that is > > directly affecting me, so I'm afraid it's unlikely that I will look into > > this with any sort of priority. Don't suppose anyone else wants to? Sam? > > Peter? > > see xml_parser_create > add parameter to this statement (in, erm, importFromString), and then there > would have to be some way of setting it to utf-8 or us-ascii (in case anyone > actually uses that). Because you can pass the constructor the filename, you > would have to pass this in as a param. Or of course not allow it here, but > only with importFromString, and have a separate function to set before > calling that. Sounds like you know what you are talking about. Looking forward to seeing your patch ;o) Cheers, Nigel |
From: Nigel S. <nig...@us...> - 2002-05-21 23:14:56
|
> When I use the replaceData() function on an empty node e.g. "<TEST/>" it > fails. > > Must be because "$this->_getTextSet(...)" returns "0" in this case. > > The insertData() function shows the same effect. Many thanks. Bug now fixed. Nigel |
From: Nigel S. <nig...@us...> - 2002-05-21 22:04:37
|
> On Friday 17 May 2002 9:03, J. Carmanns wrote: > > Found a simple solution: > > > > Add these special chars to preg_match expression on line 2672: > > > > Old: > > elseif (preg_match('/^[a-zA-Z0-9\-_]+/', $nodeTest)) { > > > > New: > > elseif (preg_match('/^[a-zA-Z0-9\-_ÄÖÜäöü]+/', $nodeTest)) { > > > > Maybe there are more chars to add? > > Looks more like a quick fix than a solution - why only German accents and not > French or anything else?! > > raises the question in my mind: why is this limitation on node names in there > anyway? Surely there is no such limitation in the xml spec? There is no such limitation. In that line we are purely trying to work out if the $nodeTest is JUST a node name, or whether it is an XPath Expression. My suggestion is that we change to: elseif (preg_match('/^[\w\-]+$/', $nodeTest)) { The PHP manual says \w is a word character where a word character is defined as: ============= A "word" character is any letter or digit or the underscore character, that is, any character which can be part of a Perl "word". The definition of letters and digits is controlled by PCRE's character tables, and may vary if locale-specific matching is taking place (see "Locale support" above). For example, in the "fr" (French) locale, some char- acter codes greater than 128 are used for accented letters, and these are matched by \w. ============= Cheers, Nigel |
From: Dan A. <da...@bs...> - 2002-05-18 20:27:37
|
Sorry, I mean to say phpxpath requires, not xml. Dan php...@li... (php...@li...) wrote: > Send Phpxpath-users mailing list submissions to > php...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/phpxpath-users > or, via email, send a message with subject or body 'help' to > php...@li... > > You can reach the person managing the list at > php...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Phpxpath-users digest..." > > > Today's Topics: > > 1. special characters (Dan Allen) > > --__--__-- > > Message: 1 > Date: Fri, 17 May 2002 13:58:37 -0700 > From: Dan Allen <da...@mo...> > To: php...@li... > Subject: special characters > > Just so everyone knows, xml requires that us use UTF-8 encoding in > your xml documents. That means it is impossible to have all of > those german/french accents in regular form. You must use XML > entities, which just like < and > replace in the output those > characters which are not alpha-numeric characters. So the phpxpath > code should not! check for these characters, you should convert them > when you make your document by using > > utf8_encode() > > Dan > > > > --__--__-- > > _______________________________________________ > Phpxpath-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpxpath-users > > > End of Phpxpath-users Digest -- It is not enough to succeed. Others must fail. -- Gore Vidal |
From: Dan A. <da...@mo...> - 2002-05-17 20:58:34
|
Just so everyone knows, xml requires that us use UTF-8 encoding in your xml documents. That means it is impossible to have all of those german/french accents in regular form. You must use XML entities, which just like < and > replace in the output those characters which are not alpha-numeric characters. So the phpxpath code should not! check for these characters, you should convert them when you make your document by using utf8_encode() Dan |
From: Peter R. <php...@pe...> - 2002-05-17 17:07:54
|
On Friday 17 May 2002 11:34, Nigel Swinson wrote: > > hm, I can see that being able to update all the nodes in a set with one > > instruction is useful, but why getDataParts and not any of the other get > > functions? > > getData() calls getDataParts(), so getData() takes a xPathQuery. Have > updated the source... Which other "get" functions are missing this? I was using your list, Nigel. getDataParts was the only one of the retrieval functions on it. > This is probably a good point to mention that ANYONE can author > documentation for the class, had a feeling you might say that :-) > > On a related issue, could you add the ability to set the source encoding. > > Ummm I don't really know where to start in coding this feature, as I don't > really understand what's required. It does sound like a useful addition > though, as I know we have many european users. It's not an issue that is > directly affecting me, so I'm afraid it's unlikely that I will look into > this with any sort of priority. Don't suppose anyone else wants to? Sam? > Peter? see xml_parser_create add parameter to this statement (in, erm, importFromString), and then there would have to be some way of setting it to utf-8 or us-ascii (in case anyone actually uses that). Because you can pass the constructor the filename, you would have to pass this in as a param. Or of course not allow it here, but only with importFromString, and have a separate function to set before calling that. |
From: Peter R. <php...@pe...> - 2002-05-17 17:07:53
|
On Friday 17 May 2002 9:03, J. Carmanns wrote: > Found a simple solution: > > Add these special chars to preg_match expression on line 2672: > > Old: > elseif (preg_match('/^[a-zA-Z0-9\-_]+/', $nodeTest)) { > > New: > elseif (preg_match('/^[a-zA-Z0-9\-_ÄÖÜäöü]+/', $nodeTest)) { > > Maybe there are more chars to add? Looks more like a quick fix than a solution - why only German accents and not French or anything else?! raises the question in my mind: why is this limitation on node names in there anyway? Surely there is no such limitation in the xml spec? |
From: Nigel S. <nig...@us...> - 2002-05-17 10:32:42
|
> hm, I can see that being able to update all the nodes in a set with one > instruction is useful, but why getDataParts and not any of the other get > functions? getData() calls getDataParts(), so getData() takes a xPathQuery. Have updated the source... Which other "get" functions are missing this? > Documentation for getDataParts doesn't mention this! The documentation for getDataParts doesn't mention this, because getDataParts() was altered since the V3.0 release to support an xPathQuery, hence it is different in the released documentation. Sorry for the confusion... I always refer the most recent version from CVS unless I explicitly state otherwise. > Surely the main reason it was 'such a common problem' was because the > documentation wasn't clear. To get a particular node, use a get function; to > get a list of nodes meeting an xpathquery criterion, use evaluate/match, and > then loop through the resulting array. Seems clear to me! I'm glad it was clear to you :o) The way the class is now it is more useable, at the expense of making novice users run less efficient calls by passing a xPathQuery rather than an absolute XPath. > > The functions are grouped as they appear in the source file, so by class > > and then in the order that they are defined in the class. I had some > > debate with Sam over the ordering in the file and we decided that the > > ordering of the functions in the source files should assist coding, and the > > doc will just have to live with it. I know it's not ideal, but I don't see > > an easy solution to re-doing the order for the doc, so I don't plan to do > > anything about this. > > perhaps what's needed is a separate FAQ: 'how do I ...' This is probably a good point to mention that ANYONE can author documentation for the class, and submit it at http://sourceforge.net/docman/new.php?group_id=36731 Sam or I have to "authorise the document" but unless you swear, curse and blashpheme it's likely to be published. Given that there were nearly 2500 downloads of 2.2, and less than 1% support requests, I wouldn't know what to put in a faq, so at this stage have no intention of authoring one myself > On a related issue, could you add the ability to set the source encoding. > Though you have the options, which enable setting of target encoding, it > looks like source definition isn't in phpxpath at present, meaning it uses > the default, which in PHP for some reason is 8859-1. I would have thought > PHP's default should be whatever is given in the xml file or, failing that, > the xml default, which is utf8 - but ... > I am currently using non-Latin1 charsets only in a database, but intend to > expand this into xml. I can foresee problems if it assumes everything is in > 8859-1 ! Ummm I don't really know where to start in coding this feature, as I don't really understand what's required. It does sound like a useful addition though, as I know we have many european users. It's not an issue that is directly affecting me, so I'm afraid it's unlikely that I will look into this with any sort of priority. Don't suppose anyone else wants to? Sam? Peter? :o) Nigel |
From: J. C. <jan...@im...> - 2002-05-17 08:01:52
|
Found a simple solution: Add these special chars to preg_match expression on line 2672: Old: elseif (preg_match('/^[a-zA-Z0-9\-_]+/', $nodeTest)) { New: elseif (preg_match('/^[a-zA-Z0-9\-_ÄÖÜäöü]+/', $nodeTest)) { Maybe there are more chars to add? Cheers Jan > -----Ursprüngliche Nachricht----- > Von: php...@li... > [mailto:php...@li...]Im Auftrag von J. > Carmanns > Gesendet: Donnerstag, 16. Mai 2002 17:19 > An: php...@li... > Betreff: special char at pos 0 problem > > > > > > * It makes use of the get_html_translation_table(HTML_ENTITIES) php > > > library > > > * call, so is limited in the same ways. At the time of > writing this > > > seemed > > > * be restricted to iso-8859-1 > > > Hmmm - iso-8859-1 should allow chars like "ä" "ü" "ö" ("ae", > "ue", "oe") and > my XML is valid - but when I use tags like <über/> and call > evaluate() then > I get an error: > > XPath error in XPath.class_cvs.php:2680 While parsing the XPath query > "/Daten[1]/Visite[1]/über[1]/*" an empty and therefore invalid > node-test has > been found. > > When I change the first letter it is fine. It only happens when > the special > char is at position 0 in the nodeName. > > Help? |
From: J. C. <jan...@im...> - 2002-05-16 15:17:54
|
> > * It makes use of the get_html_translation_table(HTML_ENTITIES) php > > library > > * call, so is limited in the same ways. At the time of writing this > > seemed > > * be restricted to iso-8859-1 Hmmm - iso-8859-1 should allow chars like "ä" "ü" "ö" ("ae", "ue", "oe") and my XML is valid - but when I use tags like <über/> and call evaluate() then I get an error: XPath error in XPath.class_cvs.php:2680 While parsing the XPath query "/Daten[1]/Visite[1]/über[1]/*" an empty and therefore invalid node-test has been found. When I change the first letter it is fine. It only happens when the special char is at position 0 in the nodeName. Help? |
From: J. C. <jan...@im...> - 2002-05-16 11:03:59
|
When I use the replaceData() function on an empty node e.g. "<TEST/>" it fails. Must be because "$this->_getTextSet(...)" returns "0" in this case. The insertData() function shows the same effect. May the source be with you |
From: Peter R. <php...@pe...> - 2002-05-16 10:20:56
|
On Thursday 16 May 2002 2:20, Nigel Swinson wrote: > > > 2. an example of evaluate/match in the sample code, and when it would be > > used. Am I right in thinking this is the only function that uses an > > xpathquery, i.e. that works with a node set and not an absolute address? > This > > was something I misunderstood when I first used the class, as I thought > you > > always had to do an evaluate before using any of the other functions. If > you > > only want one node, don't use evaluate, as it just slows things down. > > Actually as of V3, if the parameter is an $xPathQuery, then you can pass in > an xpath expression, so you don't have to call evaluate() all the time! So > all these functions can now be called using things like /A/B/C rather than > /A[1]/B[2]/C[2]. This was such a common problem that it really had to be > addressed. > > function evaluate($xPathQuery, $baseXPath='') { > function nodeName($xPathQuery) { > function removeChild($xPathQuery, $autoReindex=TRUE) { > function replaceChildByData($xPathQuery, $data, $autoReindex=TRUE) { > function &replaceChild($xPathQuery, $node, $autoReindex=TRUE) { > function insertChild($xPathQuery, $node, $shiftRight=TRUE, $afterText=TRUE, > $autoReindex=TRUE) { > function appendChild($xPathQuery, $node, $afterText=FALSE, > $autoReindex=TRUE) { > function insertBefore($xPathQuery, $node, $afterText=TRUE, > $autoReindex=TRUE) { > function setAttribute($xPathQuery, $name, $value, $overwrite=TRUE) { > function setAttributes($xPathQuery, $attributes, $overwrite=TRUE) { > function removeAttribute($xPathQuery, $attrList=NULL) { > function getDataParts($xPathQuery) { > function replaceData($xPathQuery, $replacement, $offset = 0, $count = 0, > $textPartNr=1) { > function insertData($xPathQuery, $data, $offset=0) { > function appendData($xPathQuery, $data, $textPartNr=1) { > function deleteData($xPathQuery, $offset=0, $count=0, $textPartNr=1) { hm, I can see that being able to update all the nodes in a set with one instruction is useful, but why getDataParts and not any of the other get functions? Documentation for getDataParts doesn't mention this! Surely the main reason it was 'such a common problem' was because the documentation wasn't clear. To get a particular node, use a get function; to get a list of nodes meeting an xpathquery criterion, use evaluate/match, and then loop through the resulting array. Seems clear to me! > The functions are grouped as they appear in the source file, so by class > and then in the order that they are defined in the class. I had some > debate with Sam over the ordering in the file and we decided that the > ordering of the functions in the source files should assist coding, and the > doc will just have to live with it. I know it's not ideal, but I don't see > an easy solution to re-doing the order for the doc, so I don't plan to do > anything about this. perhaps what's needed is a separate FAQ: 'how do I ...' > > 5. perhaps worth stressing with decodeEntities that it uses PHP > > functions, limited to 8859-1. > > Ok have added: > > * It makes use of the get_html_translation_table(HTML_ENTITIES) php > library > * call, so is limited in the same ways. At the time of writing this > seemed > * be restricted to iso-8859-1 > > How does that sound? it doesn't 'seem to be restricted', it is! On a related issue, could you add the ability to set the source encoding. Though you have the options, which enable setting of target encoding, it looks like source definition isn't in phpxpath at present, meaning it uses the default, which in PHP for some reason is 8859-1. I would have thought PHP's default should be whatever is given in the xml file or, failing that, the xml default, which is utf8 - but ... I am currently using non-Latin1 charsets only in a database, but intend to expand this into xml. I can foresee problems if it assumes everything is in 8859-1 ! |
From: Nigel S. <nig...@us...> - 2002-05-16 01:36:14
|
> 1. It's useful that the intro defines things like absolutexpath and > xpathquery, but the function list doesn't use these consistently, using other > terms like xpath expression or xpath string. I feel this is likely to confuse > newbies. Well spotted. Hopefully I've caught all of these now. If not please send the section reference. > 2. an example of evaluate/match in the sample code, and when it would be > used. Am I right in thinking this is the only function that uses an > xpathquery, i.e. that works with a node set and not an absolute address? This > was something I misunderstood when I first used the class, as I thought you > always had to do an evaluate before using any of the other functions. If you > only want one node, don't use evaluate, as it just slows things down. Actually as of V3, if the parameter is an $xPathQuery, then you can pass in an xpath expression, so you don't have to call evaluate() all the time! So all these functions can now be called using things like /A/B/C rather than /A[1]/B[2]/C[2]. This was such a common problem that it really had to be addressed. function evaluate($xPathQuery, $baseXPath='') { function nodeName($xPathQuery) { function removeChild($xPathQuery, $autoReindex=TRUE) { function replaceChildByData($xPathQuery, $data, $autoReindex=TRUE) { function &replaceChild($xPathQuery, $node, $autoReindex=TRUE) { function insertChild($xPathQuery, $node, $shiftRight=TRUE, $afterText=TRUE, $autoReindex=TRUE) { function appendChild($xPathQuery, $node, $afterText=FALSE, $autoReindex=TRUE) { function insertBefore($xPathQuery, $node, $afterText=TRUE, $autoReindex=TRUE) { function setAttribute($xPathQuery, $name, $value, $overwrite=TRUE) { function setAttributes($xPathQuery, $attributes, $overwrite=TRUE) { function removeAttribute($xPathQuery, $attrList=NULL) { function getDataParts($xPathQuery) { function replaceData($xPathQuery, $replacement, $offset = 0, $count = 0, $textPartNr=1) { function insertData($xPathQuery, $data, $offset=0) { function appendData($xPathQuery, $data, $textPartNr=1) { function deleteData($xPathQuery, $offset=0, $count=0, $textPartNr=1) { See the setModMatch() function to change the behaviour for when the query matches more than one node. These are the options. * - XPATH_QUERYHIT_ALL (default) * - XPATH_QUERYHIT_FIRST * - XPATH_QUERYHIT_UNIQUE But clearly, passing in an absolute XPath will mean it doesn't have to call evaluate. > 3. it would be helpful if the functions were grouped together more, e.g. if > getNode and getNodePath were together. In fact, a list of functions by > category would be useful, so that, for example, wholeText appears with the > other content retrieval functions, and it's explained how they differ. The functions are grouped as they appear in the source file, so by class and then in the order that they are defined in the class. I had some debate with Sam over the ordering in the file and we decided that the ordering of the functions in the source files should assist coding, and the doc will just have to live with it. I know it's not ideal, but I don't see an easy solution to re-doing the order for the doc, so I don't plan to do anything about this. > 4. equalNodes should read "compare two nodes" ! Fixed thanks. > 5. perhaps worth stressing with decodeEntities that it uses PHP functions, > limited to 8859-1. Ok have added: * It makes use of the get_html_translation_table(HTML_ENTITIES) php library * call, so is limited in the same ways. At the time of writing this seemed * be restricted to iso-8859-1 How does that sound? > 6. I think you mean 'relational database' - it may also be rational :-) Heh, changed. Thanks for the input Peter :o) Nigel |
From: Nigel S. <nig...@us...> - 2002-05-16 01:36:11
|
> > Actually it is the XPath of the inserted node. I change this recently but > > didn't update the header.... oops :o) > > Right, but it does not really return the full path - just e.g. > "/root[1]/TEST" but to use > the return value I need "/root[1]/TEST[1]" or with this xml > > <root><test/><test/></root> > > it would be nice if it returns "/root[1]/TEST[3]" after inserting. > > Well, I could use insertBefore() and always add "[1]" at the end of the > return value, > but that isn't the best way I think. > > Or do I miss something again? Nope, you didn't you found another bug :o) It's been fixed. You'll find it in CVS... Thanks again, Nigel |
From: Peter R. <php...@pe...> - 2002-05-15 17:20:09
|
On Tuesday 14 May 2002 19:52, Nigel Swinson wrote: > Yeah it used to return aaabbb, but as I said "the default order for the > results is now doc order". So as of CVS file version 1.86, the order > returned will be ababba. ah yes, so it does. sorry, misunderstood you |
From: Peter R. <php...@pe...> - 2002-05-15 17:20:09
|
1. It's useful that the intro defines things like absolutexpath and xpathquery, but the function list doesn't use these consistently, using other terms like xpath expression or xpath string. I feel this is likely to confuse newbies. 2. an example of evaluate/match in the sample code, and when it would be used. Am I right in thinking this is the only function that uses an xpathquery, i.e. that works with a node set and not an absolute address? This was something I misunderstood when I first used the class, as I thought you always had to do an evaluate before using any of the other functions. If you only want one node, don't use evaluate, as it just slows things down. 3. it would be helpful if the functions were grouped together more, e.g. if getNode and getNodePath were together. In fact, a list of functions by category would be useful, so that, for example, wholeText appears with the other content retrieval functions, and it's explained how they differ. 4. equalNodes should read "compare two nodes" ! 5. perhaps worth stressing with decodeEntities that it uses PHP functions, limited to 8859-1. 6. I think you mean 'relational database' - it may also be rational :-) |
From: J. C. <jan...@im...> - 2002-05-15 10:18:19
|
> Actually it is the XPath of the inserted node. I change this recently but > didn't update the header.... oops :o) Right, but it does not really return the full path - just e.g. "/root[1]/TEST" but to use the return value I need "/root[1]/TEST[1]" or with this xml <root><test/><test/></root> it would be nice if it returns "/root[1]/TEST[3]" after inserting. Well, I could use insertBefore() and always add "[1]" at the end of the return value, but that isn't the best way I think. Or do I miss something again? Cheers Jan |
From: Nigel S. <nig...@us...> - 2002-05-14 20:45:31
|
> The return value of appendChild() and replaceData() are currently bool. But > it would make sens if they would return the abs. Xpath string of the > inserted node. (Something to do). Actually it is the XPath of the inserted node. I change this recently but didn't update the header.... oops :o) Nigel |
From: Philipp L. <le...@hi...> - 2002-05-14 18:54:18
|
From: "Peter Robins" <php...@pe...> > > > Imagine you want to build a table-of-contents for an XHTML page. > > > The most reasonable expression to me seems to be: > > > //h1 | //h2 | //h3 | //h4 | //h5 | //h6 > > > and then process this e.g. building a nested list. > > can you not use starts-with("h") function to return them all in one node-set? > Nope, as that might also return "html", "head", and "hr". (I could use a little for-loop and build the string, but why bother? XHTML is restricted to 6 levels of headings.) |