Sokolov Evgeniy wrote:
If you are very busy, you can answer "yes, yes, no" :)
1.
Setting the value using the value property should behave like setting the value
via
the DOMAttr constructor - input should be treated as literal text
But in this case value does not be treated:
$attr = new DOMAttr('test', 'foo&bar');
var_dump($attr->value);
string(11) "foo&bar"
So, this is bug?
May be I misunderstood something?
The above output is correct. Values of a DOMAttr deal strictly with text
literals. The only time escaping should be performed is when the
attribute value is being serialized in a document context - i.e.
DOMDocument::saveXML(DOMAttr) - which would end up outputting the value
foo&bar
2. I saw you comment in the bug page.
May I write test for this cases and in this testcase show how avoid this "bug"?
Test cases are more than welcome.
3. May be add $DOMAttr->getEntitiesValue() method? Because I think
htmlspecialchars_decode function are not equal libxml function
xmlEncodeEntitiesReentrant (this function use entity table). Is this
function used as analog for htmlspecialchars_decode in libxml?
Unfortunatelly, I can't find libxml analog function for
htmlspecialchars php function :(
htmlspecialchars would work fine to at least allow the assignment in all
cases as the issue really only revolves around the use of & and <. Due
to the nature of the issue I am thinking about the possibility of a
rawValue property on DOMAttr which would conform to the correct setter
behavior.
Thank you.
2010/2/14 Rob Richards <rricha...@php.net>:
Sokolov Evgeniy wrote:
Hi, I wont fix this bug: http://bugs.php.net/bug.php?id=47532, but
have some questions. Can you help me?
There is the test case: http://pastebin.org/91030
First, I careful that when we fix this bug, we have broken BC, because
now when we write $attr->value = "foo&bar"; - value has been
escaped and in var_dump($attr->value) we got "foo&bar". For fix this
bug we must remove escaping. This is right?
Second, for remove escaping I think we need use this patch:
Index: attr.c
===================================================================
--- attr.c (revision 294790)
+++ attr.c (working copy)
@@ -193,7 +193,7 @@
convert_to_string(newval);
}
- xmlNodeSetContentLen((xmlNodePtr) attrp, Z_STRVAL_P(newval),
Z_STRLEN_P(newval) + 1);
+ xmlNodeAddContentLen((xmlNodePtr) attrp, Z_STRVAL_P(newval),
Z_STRVAL_P(newval) + 1);
if (newval == &value_copy) {
zval_dtor(newval);
This patch fix this cases:
$attr = new DOMAttr('test', 'foo&bar');
var_dump($attr->value);
$attr->value = "foo&bar";
var_dump($attr->value);
but in this case we got empty value:
$doc = new DOMDocument;
$attr = $doc->createAttribute("foo");
$attr->value = "foo&bar";
var_dump($attr->value);
Can you explain why?
in first two cases wiil be call xmlNewProp libxml2 function, in last
case - xmlNewDocProp. Both this functions return same variable type.
The patch is incorrect as its changing the wrong thing. The retrieval of the
value is correct, it's the setting which has an issue. Setting the value
using the value property should behave like setting the value via the
DOMAttr constructor - input should be treated as literal text. Wont be
changing the behavior of the value property due to BC.
Rob
--
Evgeniy
Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
