Bug #18236 Updated: EXACT HTTP POST data access
| From: | sesser@php.net | Date: | Tue, 09 Jul 2002 13:59:44 +0000 |
| Subject: | Bug #18236 Updated: EXACT HTTP POST data access | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-13604@lists.php.net to get a copy of this message | ||
ID: 18236
Updated by: sesser@php.net
Reported By: foobardotcom@poczta.onet.pl
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux cyberhq 2.4.19-pre6 #2 SMP
PHP Version: 4.2.1
New Comment:
here is the url:
http://www.w3.org/TR/html401/interact/forms.html#h-17.4
Previous Comments:
------------------------------------------------------------------------
[2002-07-09 09:57:00] sesser@php.net
The claim that [] violates html 4.0 is simply wrong.
The html 4.0 specification clearly states that the name
attribute for the input tag is of the type CDATA and not
of type ID/NAME.
------------------------------------------------------------------------
[2002-07-09 07:42:15] markonen@php.net
After a brief debate on #php.bugs, it looks like the only
suitable alternative syntax would be
array-key- = value
or
array_key_ = value
i.e. substituting a hyphen or an underscore for the square
brackets. This way we'd be compatible with the "Namespaces
in XML" recommendation (at http://www.w3.org/TR/REC-xml-
names/) which gives meaning to colons in name tokens.
The place to implement this would be
php_register_variable_ex() in main/php_variables.c. There
will be a small performance penalty.
------------------------------------------------------------------------
[2002-07-09 07:07:53] markonen@php.net
Right. We need a standards-compliant, alternative syntax
for the current array[] feature. The magical convert-all-
multiply-defined-vars-to-an-array stuff isn't going to
happen. There are just too many issues to deal with on that
road.
------------------------------------------------------------------------
[2002-07-09 06:53:25] m.ford@lmu.ac.uk
The problem here is not really needing to type the extra two
characters, but that the resulting name/id is *not* *in* *conformance*
*with* *HTML4.0*, which states that:
> ID and NAME tokens must begin with a letter ([A-Za-z])
> and may be followed by any number of letters, digits
> ([0-9]), hyphens ("-"), underscores ("_"), colons (":"),
> and periods ("."). [http://www.w3.org/TR/html401/types.html#h-6.2]
So we either have to write non-conformant HTML (not even permitted at
some sites!), or program round it (e.g. by naming form elements foo_1,
foo_2... and then searching for them in a loop), which is inefficient.
Besides this one, bugs #10502, #15498 and #16195 are all OPEN feature
requests for the "automatically convert to array" functionality, so
there is a fair level of demand for it. Besides, a language that
claims to be "especially suited for Web development"
[http://www.php.net/] should not actually prevent the writing of
standards-conformant Web pages.
I wish I had the spare time to investigate the PHP sources and write a
patch for this myself, but I just don't. (I only just find time to
read the lists most days, but sometimes I even have to dump 100s of
messages unread!)
Cheers!
------------------------------------------------------------------------
[2002-07-09 05:00:29] hholzgra@php.net
maybe $HTTP_RAW_POST_DATA is what you are looking for?
btw: please define "behave correct on select multiple"
what is so bad about specifying that you are going to
fill an array? the alternative would be to create arrays
if multiple values are set while single selections
would still become simple strings as there is no way for
PHP to know that it was generated from a <select multiple>
so it's just a tradeof: having to type two more characters
as element name or taking care that both string and array
inputs are supported in the form processing code
our approach is obviously the first one
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/18236
--
Edit this bug report at http://bugs.php.net/?id=18236&edit=1