Re: Re: cvs: pear /Structures_DataGrid/DataGrid/Renderer HTMLTable.php
| From: | Olivier Guilyardi | Date: | Fri, 03 Mar 2006 19:12:25 +0000 |
| Subject: | Re: Re: cvs: pear /Structures_DataGrid/DataGrid/Renderer HTMLTable.php | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-41629@lists.php.net to get a copy of this message | ||
Justin Patrin wrote:
> On 3/3/06, Olivier Guilyardi <ojaiml@nerim.net> wrote:
>
>>>>+ * Note: users who want their GET parameters separated by
>>>>+ * "&" instead of "&" (see Bug
>>>>#6151) should properly
>>>>+ * configure the "arg_separator.output" php ini setting
>>>>*/
>>>> $url .= http_build_query(array_merge($common, $get));
>>>
>>>I don't think that this is right. http_build_query could be used for
>>>non-HTML output within the same script and changing the php.ini
>>
>>Agreed. Everything would be simpler if http_build_query() accepted an additional
>>$separator argument.
>
> Yes.
>
>>>IMHO this option is akin to the infamous magic_quotes_gpc and should
>>>be worked around in the same manner. It can be used as the same kind
>>>of premature escaping mechanism.
>>
>>Do we have to provide a "workaround" or is this simply a PHP bug ? Why to
>>provide workarounds for what can be fixed at its root ?
>
> magic_quotes_gpc is also IMHO a PHP bug. Along with overloading. But
> that's another conversation.
There's a big difference between magic_quotes_gpc and http_build_query(). The
former is a very old PHP design choice, but the later is a pretty recent
feature. So IMO it is still time to post a PHP bug about http_build_query()
> I would say that either you shouldn't use this function due to
> possible inconsistencies or check the option and run htmlentities if
> the option isn't set right.
Actually, a solution is to paste the PHP/Compat/Function/http_build_query.php
content into new methods inside the HTMLTable driver. That's what's done in
Pager if IIRC. There I could simply use any separator I like. But I'm not going
to do this. Too many lines for a such little workaround.
Now, as you said, by checking what the content of arg_separator.output is before
calling htmlentities I would avoid the "&amp;" problem. This would be a
quite short workaround, I must confess.
Actually, htmlentities even seems to be what PHP maintainers recommend...
http://bugs.php.net/bug.php?id=30049
> My point is really that it's the job of the output code to make sure
> that the HTML is escaped correctly, it shouldn't depend on the user
> altering an option.
Agreed, but PHP options are not so obscure, they are parameters that a lot of
people can change to configure their scripts. But some can't, that's true.
> But then again, maybe I'm completely off-base here. You're welcome to
> leave it however you want...
No, you're quite right about the problem... Okay, so I'm going to implement the
htmlentities() workaround.
Do you think that a new PHP bug makes any sense ?
Thanks for your comments.
--
og