Description: ------------ "Bug #3601 htmlentities needed for data". If an application is going to store structured information such as html, it will probably make these changes on insert or on update not on retrieval, therefore the output of Structures_Datagrid should not use htmlentities()(unless specified in the formatter). An attempt to add links or html into the datagrid will require adding a dummy formatter that simply returns the content just to bypass htmlentities(). This doesn't seem very logical or efficient.

Storing formated data as html in a database is not a good practice from my point of view. The database is where unformatted information is supposed to be stored, then some application is responsible for formatting it in html, pdf, xml, whatever... For some CMS or Forum applications it may make sense, but I still consider that it is a bad practice, as it mixes information and formatting, which are two different things. That's why I consider that SDG's default behaviour is ok. Please note that the rendering layer of SDG is about to be rewritten (see bug #5859), and that it should be easier to modify such default behaviour in the future. Anyway, I agree that it must be possible to disable this behaviour for some specific needs.

I don't want to get into an argument over separation. "My aversion to a rule-of-thumb separating style from content comes partly from a belief that some style is content. Not style to attract attention, but style to inform." "It’s style that cannot be dissected from content without bleeding away informative power." http://www.alistapart.com/articles/separation/ I don't like this addition of htmlentites() because it is making an assumption of what I am asking it to do. I am asking it to ouput data from the database to a tabular structure, nothing more. The fact that in order to simply display information "as-is" requires a dummy formatter function (or extend the render class as in bug #5859) should be a flag that this is not the proper default.

I see your point, and am not a separation extremist myself. Now, let's try to forget theoretical considerations for one sec. Isn't the current deault behaviour the right one for most users ? (I do believe that it is). Isn't the solution simply to add a way to _disable_ html entities conversion ? For example : HTMLTable::setEntitiesConversion($status) Can you tell me what you were precisely trying to do when this behaviour disturbed you ?

I have the same problem. I think it would be nice to be able to tell the renderer not to execute htmlentities on the cells. For now, I guess we should go for the "dirty" way of extending the HTML_Table renderer to disable this behaviour.

I also would like to see a way to turn off the htmlentities() application, either on a full table basis or a colum/cell basis. I absolutely agree that the current behavior is the proper behavior in most cases for most users; I just happen to be a user who wrote his own framework that allows for application of callback funcs to modify cell contents (to, say, show an image instead of just the URL, or make an active link). Without a "disable htmlentites" option, I'll need to rewrite a fair bit of code to re-map callbacks through the column formatter system (which I maybe should have done at the first place, looking back), or extend the renderer (which seems kind of silly to modify a single line of code).

my only point here is that the default behavior should be to output without using htmlentities(). I think the idea of storing xhtml / xml or other markups in the database used to be bad practice. But things have changed. Everything is written in xhtml/xml; help files, content for the web, content for applications, lots of software apps use some form of markup in their files, such as pdf ai psd. Not just web-pages use markup. PDA's, phones, Tivo, children's handheld games, all use xml/xhtml or some sort of markup. I am not talking about just weblog apps and phpForums, EVERYTHING uses markup now. We even have intrepid soldiers of markup use xhtml/css to print books (http://www.alistapart.com/articles/boom). There are so many tools available that can easily handle / manipulate xml that there is no reason not to store xml/xhtml in the databse for those inseparable pieces of structure. And when a tag is deprecated these tools are going to be there to update our db's easily. So the real question is how do you propose we store links in our content, how do we store paragraphs, headings, line breaks, lists? is "\n" really any different than "<br>". txt is out xml is in.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. The HTMLTable renderer has new option : "convertEntities". It is turned on by default, but you can disable it to avoid special html caracters conversion.