Daniele Grillenzoni wrote:
On 20/05/2009 2.45, Nathan Rixham wrote:
Daniele Grillenzoni wrote:
On 19/05/2009 18.09, Andrew Ballard wrote:
On Tue, May 19, 2009 at 10:11 AM, Ford, Mike<M.Ford@xxxxxxxxxxxxxx>
wrote:
On 19 May 2009 14:37, Daniele Grillenzoni advised:
My complaint is this: a I can have a select multiple with a
normal name,
which is allowed by every spec, but PHP requires me to use []
in order
to properly retrieve the values.
I really don't understand the problem with this -- in fact, I find it
quite useful to distinguish inputs which may have only 1 value from
those which may be multi-valued. And it all depends on what you
mean by
a "normal" name, of course -- no current (X)HTML spec disallows [] as
part of a name attribute, so in that sense a name containing them
could
be seen as perfectly normal...!! ;) ;)
Can you explain why this is such a hang-up for you, as I haven't seen
anything in what you've posted so far to convince me it's any kind of
problem?
Cheers!
Mike
I can't speak for the OP, but I've always thought it somewhat odd. An
HTML form should be able to work correctly without modification
regardless of the language that receives the input. As it is, it makes
the HTML for a form implementation specific. You might be able to use
ASP correctly process a form originally targeted toward PHP, but you
could not similarly take a form designed for ASP and process it with
PHP without modification.
It also impacts the use of client-side JavaScript. Consider a simple
page like this:
sundae.html
==============
<html>
<head>
<script>
function countToppings() {
var totalToppings = 0;
var toppings = document.sundae.toppings;
// To work with PHP, the above line would have to be changed:
// var toppings = document.sundae.elements['toppings[]'];
if (toppings.length> 1) {
for (var i = 0; i< toppings.length; i++) {
if (toppings[i].checked) totalToppings++;
}
} else {
if (toppings.checked) totalToppings++
}
if (totalToppings == 0) {
confirm("Are you sure you don't want any toppings on your sundae?");
} else if (totalToppings> 3) {
alert("Wow! That's a lot of toppings!");
} else if (totalToppings == 1) {
alert("You only want one topping.");
} else {
alert("You have selected " + totalToppings + " toppings! Yummy!");
}
}
</script>
</head>
<body>
<form name="sundae">
<div>
<fieldset>
<legend>Toppings</legend>
<input type="checkbox" id="toppings-sprinkles" name="toppings"
value="sprinkles"/> <label
for="toppings-sprinkles">sprinkles</label><br/>
<input type="checkbox" id="toppings-nuts" name="toppings"
value="nuts"/> <label for="toppings-nuts">nuts</label><br/>
<input type="checkbox" id="toppings-fudge" name="toppings"
value="fudge"/> <label for="toppings-fudge">fudge</label><br/>
<input type="checkbox" id="toppings-caramel" name="toppings"
value="caramel"/> <label for="toppings-caramel">caramel</label><br/>
<input type="checkbox" id="toppings-strawberries" name="toppings"
value="strawberries"/> <label
for="toppings-strawberries">strawberries</label><br/>
</fieldset>
<input type="button" name="count" value="Count My Toppings"
onclick="countToppings()"/>
<input type="submit" name="order" value="Order" />
</div>
</form>
</body>
</html>
The above form, if submitted, could build a perfectly valid query
string of
"?toppings=sprinkles&toppings=nuts&toppings=fudge&toppings=caramel&toppings=strawberries".
In the grand scheme of things, these are just subtleties that can
easily be handled. Since my first major experience with a web language
was PHP (after a very brief dabble in PERL) before I took a turn at
ASP/VBScript, I'm used to it and it isn't a "hang-up" for me. But
something about it never seemed quite "right" to me either. :-)
Andrew
Andrew captured perfectly what I meant.
"?toppings=sprinkles&toppings=nuts&toppings=fudge&toppings=caramel&toppings=strawberries"
is a valid querystring that php sort of fail at understanding.
I have nothing against supplying a string/array clarification system
based on the name with/without the square brackets, but short of
manually parsing the querystring/request headers, I have no
alternative to that.
Also my original problem came when I had to parse the results of a
form I did NOT originally create, not to mention forms from external
sources...
I don't hate PHP and I don't want to throw off people who like the []
system, just give me an alternative with a small overhead. :P
quick work around :) (could be improved)
<?php
function fixGet() {
$newGet = array();
foreach($vals=explode('&',$_SERVER['QUERY_STRING']) as $i => $pair ) {
$pair = explode( '=' , $pair , 2 );
if( !isset( $newGet[$pair[0]] ) ) {
$newGet[$pair[0]] = $pair[1];
} else {
if( !is_array($newGet[$pair[0]]) ) {
$newGet[$pair[0]] = array( $newGet[$pair[0]] );
}
$newGet[$pair[0]][] = $pair[1];
}
}
$_GET = $newGet;
}
print_r( $_GET );
fixGet();
print_r( $_GET );
?>
outputs:
Array
(
[toppings] => caramel
[order] => Order
)
Array
(
[toppings] => Array
(
[0] => nuts
[1] => fudge
[2] => caramel
)
[order] => Order
)
Yeah, and php://input should be able to handle $_POST, but custom
functions ftl, the idea of having useless overhead for simple stuff like
this makes me angry.
aye, at least it is possible to implement / work around quickly in
userland - not sure if it makes me angry but things like this could be
implemented easily internally I'm sure - wonder how a change like this
would affect bc though, last thing you'd want is a tonne of sites
breaking down because of a change like that - regardless that's not for
my thought or debate.
btw as pointed out that chunk of code certainly isn't optimised or
sanity checked for production use, and could easily (+should) be
improved, but then that's what you get in a quick response on a mailing
list - something to point you in the right direction and work with.
I do have to point out though that overhead with things like this aren't
exactly problematic or noticeable - in-fact unless you have a massively
optimised application with cache's everywhere, perfect sql, perfect
code, perfectly suited design pattern, stripped out all unnecessary
code, classes, frameworks etc etc etc then its not really worth
considering imho.
+ in userland you've pretty much only got the options of preg_, split,
and explode - and explode is the fastest.
we all know how it is, nothings perfect, thankfully in php "flaws" or
"design features" can generally be worked around in a few lines of code
- and the internals team do a great job, think of the money we've made
from using php, ever sent any of it to the internal team? ever paid for
your php? bought a license? etc - and as coders that's what we do, we
code solutions to little things like this :p
happy wednesday
ps: daniele, that's not all pointed at you - had another reply offlist
along the lines off "That's an awful lot of overhead and CPU time
because you don't want to use []... more"
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
