ID: 745
Updated by: sniper@php.net
Reported By: be at shonline dot de
-Status: Analyzed
+Status: Wont fix
-Bug Type: Scripting Engine problem
+Bug Type: *General Issues
Operating System: *
PHP Version: 4.3.0-dev
New Comment:
Little bit of thinking and it's obvious.
Instead of using name="foo[123]", you should use name="foo[123][]"
which will end up being a full array:
Array
(
[blah] => Array
(
[123] => Array
(
[0] => 12
[1] => 16
)
)
)
To access the values:
$foo[123][0] == x value
$foo[123][1] == y value
Or just do not define the index and use name="foo[]" and
you'll get:
Array
(
[blah] => Array
(
[0] => 14
[1] => 15
)
)
There's no point in 'fixing' this in PHP.
Previous Comments:
------------------------------------------------------------------------
[2002-12-02 18:18:20] pollita@php.net
Given raw post data of: foo%5B123%5D.x=5&foo%5B123%5D.y=10
I disagree with having the script engine turn that into:
[foo] => Array (
[123] => Array (
[x] => 5
[y] => 10
)
)
as this would break backward compatability (though I doubt many scripts
are using this to be honest).
There are two sensical solution that pop into my head:
#1)
[foo] => Array (
[123] => 10 // For BC
[123.x] => 5
[123.y] => 10
)
From an engine stand point all this says is "if the ] is not at the end
of the varname, move it there."
However, I don't like this idea either. While it makes the data
accessable without breaking anything, it's just plain ugly.
#2)
[foo] => Array (
[123] => 10 // For BC
)
[foo_x] => Array (
[123] => 5
)
[foo_y] => Array (
[123] => 10
)
From an engine stand point all this says is "if there is a [] block
which is not at the end of the varname, make one copy of the var with
the end truncated, then move the [] block to the end and export that
varname as well."
i.e.: foo[123]bar => foo[123] && foobar[123]
And come to that it would want to include cases where there is non []
text between [] blocks:
i.e.: foo[123]bar[456] => foo[123][456] && foobar[123][456]
or possibly...
foo[123]bar[456] => foo[123][456] && foo[123][bar][456]
I can get behind this approach... At least in principal... But I don't
believe in its need enough to work on it unless it gets a several +1s.
It also has the disadvantage of allowing scripters to get used to
naming their form elements incorrectly. (Not that the image example is
incorrect, per se, but it's a special case as the browser modifies the
name beyond the control of the designer).
------------------------------------------------------------------------
[2002-07-01 08:49:43] sniper@php.net
Raw post data and resulting variables:
foo%5B123%5D.x=5&foo%5B123%5D.y=10
Array ( [foo] => Array ( [123] => 10 ) )
bar%5B%5D.x=5&bar%5B%5D.y=10
Array ( [bar] => Array ( [0] => 5 [1] => 10 ) )
foobar.x=5&foobar.y=10
Array ( [foobar_x] => 5 [foobar_y] => 10 )
Not very consistent..
------------------------------------------------------------------------
[2001-12-12 15:02:08] zak@php.net
Personally, I would rather avoid adding configuration
directives for something as small as this! :)
------------------------------------------------------------------------
[2001-12-12 14:45:10] hholzgra@php.net
i'd like to have $whatever[...][...][x] and $whatever[...][...][y] in
all cases, maybe
with ini switches for old, new or both ...
------------------------------------------------------------------------
[2001-12-12 14:33:25] zak@php.net
Maybe we should just make $foo_x[123] and $foo_y[123]
available in addition to $foo[123]? That should keep BC
and still do things right, though we might want to change
the value of $foo[123] to something like 'x,y' instead of
just y???
------------------------------------------------------------------------
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/745--
Edit this bug report at http://bugs.php.net/?id=745&edit=1