Re: Re: Parsing of forms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux