I have built a little editable table working with a dhtmlxgrid component.
I’m using a DataProcessor too and gridDataLink.php for saving and feeding my grid.
When I try to insert some special characters into a cell (ones which need to be escaped in XML, that is to say : <,>,&), gridDataLink.php seems to produce a non valid XML (I guess it doesn’t add [!CDATA…) in the value.
When I try to insert a ‘+’ into a cell, as DataProcessor escapes values when passing infos to griDatalink.php, it results as a white space in database.
What is the best way to deal with thoses characters ?
Shouldn’t gridDatalink.php allways produce a XML with escaped values ?
What about the ‘+’ character ?
The latest version of dataprocessor already updated to resolve such problem ( additional mode - dp.enableUTFencoding(true) - added ) - please contact us directly if you need updated js file.
Also you can apply necessary modification to your current version of dhtmlxdataprocessor.js, just locate the next string in it
escape(…
and replace with
encodeURIComponent(…
( there are about 10 occurences of string which need to be updated )
Such update will be equal to usage of latest code with enableUTFencoding enabled.
Thanks for your quick answer.
Indeed, using encodeURIComponent instead of escape, correct “+” problem as ,encoding in that mode , will transforms + into a different code from white space.
But, It doesn’t correct non valid XML error when you put “& < > “.
I have modified gridDataLink.php accordingly :
…
function getXMLGrid(){
$where=(string)$this->c->table->where;
$sql=“SELECT * FROM “.$this->c->table[“name”];
if ($where!=””)
$sql.=” WHERE “.$where;
$res=mysql_query($sql);
if ($res)
while ($data=mysql_fetch_assoc($res)){
echo “<row id=””.$data[(string)$this->c->table->key[“name”]].”">";
foreach ($this->c->table->param as $param)
echo “<![CDATA[”.$data[(string)$param[“name”]]."]]>";
echo “”;
}
}
…
Which prevents form getting non valid XML when special chars are inserted in database.
Do you see any reason to not to implement this modification as the default behavior ?
Do you see any reason to not to implement this modification as the default behavior ?
It will not harm anything for sure, we will add it as part of standard solution