• (cs) in reply to Rich
    Anonymous:

    Not that I want to be seen to be defending PHP particularly (I use it a fair bit but I am a sysadmin, no longer a full-time programmer) but it must be remembered that PHP originated as a very simple language to make designing simple homepages quick and relatively painless. Crap such as [] is pretty easy to understand in that context, much like the magic quotes and other braindead stuff.

    That said, it should have deprecated by now and been replaced with something saner. I did ask about it recently and was told that there were technical reasons or ot was "too difficult" to do things any other way (which I immediately rebutted of course). I took that to mean that the PHP developers had not yet had the appropriate epiphany. I am sure they will. But in the meantime, the insanity remains.


    That's why I don't like PHP. It started as a quick hack for simple things but the shortcomings are so deep within its core that it will never be able to become a really good language.
  • (cs) in reply to CodeRage
    CodeRage:

    Yeeesh, I'm glad I don't use PHP.  How hard is it to parse the key/value pairs in the http post or get, and then build an array for any key that has more than one occurance...Anyway, thanks to all for clarifying this to me.


    The problem is that if there is excactly one occurrence, it might be just by pure luck, because the user checked one of several checkboxes. The program expects an array and crashes; unfortunately, in PHP, to make things simple, the program cannot tell the HTTP parser if it expects a single occurrence (therefore a simple variable) or an array.
  • (cs) in reply to WWWWolf
    WWWWolf:
    qbolec:
    Alex Papadimoulis:
          
    function submit()
    {
      document.location.href = 'insert.php?chosen=' + 
         document.selecter.checkedValues.value;
      return false;
    }
    
    I'm afraid of:
          
    //insert.php
    mysql_query("INSERT INTO MyOrder (ID) VALUES ($chosen)");
    



    Yeah, let's combine a great big web app design flaw with a PHP-specific design flaw: SQL injection annnnnd register_globals... =)

    Yeah, I'm almost 100% sure he's using register_globals, otherwise he would probably came up what's $_REQUSET for...

    As WTF as it was it perfectly matches the design of http://www.realestate.com.au/cgi-bin/rsearch?a=sf&s=qld&t=ren&snf=rbs  (take a while to play with the select box and watch the textbox)

    ..and I was asked to make a new page with similar in feel&look to this one - I told them that this multi-selectbox 'rescripting' is retarded and counter-intuitive to anyone that handled at least one Window's app before. They told me, that this exactly meet future administrators of the new website description... (retarded and never used Windows apps??) and I was told to cooperate and just copy the javascript from this site ... (well I obviously took a look at that script, but no, I didn't copy it...)

    To calm my guilty conscience, I made sure that this script is easy to delete from the future release, when the new hax0rz, capable of handling selectboxes will be born to take over the administration of my site.

    (And to make it perfectly clear, the www.realstate.com.au had nothing to do with my job, it was just a reference website, to help explain to me how should I implement the new site for the contractor)

  • (cs) in reply to Rich

    I deal with ASP a lot. Essentially all parameters passed in are "StringList"s. The default return value of a StringList is all elements concatenated with commas.

    So, for the URL: thing.asp?test=1&test=2

    Request.QueryString("Test")="1,2"

    However, you can also do:

    Request.QueryString("Test").Count=2
    Request.QueryString("Test").Value(0)="1"
    Request.QueryString("Test").Value(1)="2"

    (Which can be shortened down to Request.QueryString("Test")(0) as "Value" is the default parameter).

    So there's no problems with commas, if you use the objects the way they're meant to be used.

  • (cs) in reply to ammoQ
    ammoQ:

    The problem is that if there is excactly one occurrence, it might be just by pure luck, because the user checked one of several checkboxes. The program expects an array and crashes; unfortunately, in PHP, to make things simple, the program cannot tell the HTTP parser if it expects a single occurrence (therefore a simple variable) or an array.

    OMG! Is it that hard to do: (ok - this is WTF - php request processing in php):
    foreach($req as $key => $val) {
        if(!array_key_exists($key, $_GET))
           $_GET[$key]=$val;
        else {
           if(is_array($_GET[$key]))
              $_GET[$key][]=$val;
           else {
              $tmp=$_GET[$key];
              $_GET[$key]=array($tmp, $val);
           }
        }
    }
    It's not a rocket science people...
    Sorry if there's something wrong with code - haven't used php for a while.
  • Rich (unregistered) in reply to ammoQ
    ammoQ:

    The problem is that if there is excactly one occurrence, it might be just by pure luck, because the user checked one of several checkboxes. The program expects an array and crashes; unfortunately, in PHP, to make things simple, the program cannot tell the HTTP parser if it expects a single occurrence (therefore a simple variable) or an array.


    Simple, have $_REQUEST, $_POST and $_GET that work the normal way and have $_REQUEST_ARRAYS, [etc] that return all request values as arrays (whether multi-valued or not). Or have a function that looks into the GET or POST data and works an array if you'd rather do it on the fly than take the processing hit up-front (it's possible to do this yourself but it should be a language feature).

    Point is that client usage shouldn't be arbitrarily limited by the server (in something with a featureset like PHP has)

    Rich
  • (cs) in reply to viraptor
    viraptor:
    ammoQ:

    The problem is that if there is excactly one occurrence, it might be just by pure luck, because the user checked one of several checkboxes. The program expects an array and crashes; unfortunately, in PHP, to make things simple, the program cannot tell the HTTP parser if it expects a single occurrence (therefore a simple variable) or an array.

    OMG! Is it that hard to do: (ok - this is WTF - php request processing in php):
    foreach($req as $key => $val) {
        if(!array_key_exists($key, $_GET))
           $_GET[$key]=$val;
        else {
           if(is_array($_GET[$key]))
              $_GET[$key][]=$val;
           else {
              $tmp=$_GET[$key];
              $_GET[$key]=array($tmp, $val);
           }
        }
    }
    It's not a rocket science people...
    Sorry if there's something wrong with code - haven't used php for a while.

    So the client program has to check the type of $_GET[$key] to see if it gets an array or a simple value this time? I think this is exactly the problem the PHP guys wanted to avoid. Because even if there are 10 equally-named checkboxes, $_GET[$key] would be a simple value if the user has checked only one of them. Or it would not exist at all if none were checked.
  • (cs) in reply to Rich
    Anonymous:

    Simple, have $_REQUEST, $_POST and $_GET that work the normal way and have $_REQUEST_ARRAYS, [etc] that return all request values as arrays (whether multi-valued or not). Or have a function that looks into the GET or POST data and works an array if you'd rather do it on the fly than take the processing hit up-front (it's possible to do this yourself but it should be a language feature).

    Yes, that would be the way to go, but it's not compatible with existing programs (register_globals anyone?). And I guess it's against their philosophy. I think they rather keep the program simple and taint the HTML code instead.

    Point is that client usage shouldn't be arbitrarily limited by the server (in something with a featureset like PHP has)

    Couldn't aggree more. Read my "That's why I don't like PHP" post.
  • .NET Developer (unregistered)

    No Idea.......

  • (cs) in reply to ammoQ
    ammoQ:

    So the client program has to check the type of $_GET[$key] to see if it gets an array or a simple value this time? I think this is exactly the problem the PHP guys wanted to avoid. Because even if there are 10 equally-named checkboxes, $_GET[$key] would be a simple value if the user has checked only one of them. Or it would not exist at all if none were checked.

    Basicaly yes. However, if you use name="arr[]", you still have to check if that array exists. If nothing is there, then there is no $_GET[arr]. If you play defensive, you should also check if is_array($_GET[arr]) anyway. Not checking it and expecting it to be a value, can give you "array", or null for example - and you don't want that to happen.
    So if you check it anyway - you can as well add this one else case, where it's a single string.
  • (cs) in reply to Licky Lindsay
    Anonymous:
    Anonymous:
    Anonymous:
    PHP apparently discards all but the last value unless the name ends with [], which isn't even legal HTML.


    Umm.. how so? If my memory serves me correctly, "name"-attribute of input-elements is of type CDATA, which means "a sequence of characters from the document character set"... so ending a name with [] is just about as allowed in HTML as ... well, just about anything :)


    PHP isn't the only "framework" that uses that kind of thing either. Struts, for instance, uses the hell out of it.

    Captcha: error

    actually, i've seen input tags with the names login[username] and login[password], yay for pre-grouping the data.
  • (cs)

    Is it just me, or naming all check-boxes "chosen" (or in general in with the same name) is a little bit counter-intuitive? I prefer to think, that check-boxes means items that you want to or don't want to choose, so each of them is separate thing, so I usually name them "choice_0",...,"choice_100", so then you can just perform in  PHP simple scan

    foreach($_REQUEST as $key)if( startswith($key,"choice_")){do something;}
    or
    for($id=100;$id--;)if(isset($_REQUEST["choice_$id"])){do something;}
    ...ok, maybe it's not so simple as it could be with
    foreach($_REQUEST['choice'] as $id){do something;}
    , but at least I know what I'm doing...and the PHP engine knows what's going on...I don't like (or maybe : I do not get) the idea of server deciding whether the variable should be an array or not depending on the number of submitted infos...I also think, that the way to distinguish this two different cases by adding "[]" at the end of the variable is very elegant and concrete.
  • (cs) in reply to AI0867

    AI0867:

    actually, i've seen input tags with the names login[username] and login[password], yay for pre-grouping the data.

    ..and I would try to submit handcrafted form with <input name=login[isadmin] value=yep> just to make sure the site is worth of seeing my password...

  • (cs)

    Hm... so if I got that right, the author of that Javascript didn't trust HTML forms, and instead wrote his own submit-function? Brillant.

    --

    Oh, and the description of that Developmestuction sounds uncomfortably similar to what my predecessor left me. I've started using some of the apparently less intuitive approaches with new web apps (such as versioning, and separate locations for testing and production), but my boss already complained that the system was far too complex, and wouldn't it just be enough to rename the file to "index.php.old", "index.php.old.1" etc. whenever I changed it?


  • (cs) in reply to Arancaytar

    Oh, I just noticed that the checkboxes will be sent as a comma-separated list this way. Nifty but... why the heck would someone do that? I've made a form like this before and there is absolutely NO difficulty with parsing those parameters in a normal way on the PHP backend, and elegantly.

    The sort of people who think otherwise are responsible for PHP enjoying a reputation that ranks it just above VBscript and just below COBOL.

  • (cs) in reply to CodeRage
    CodeRage:
    Yeeesh, I'm glad I don't use PHP.
    LOL, every thread...
  • (cs) in reply to mratzloff

    The debate about implementation is just a matter of degree.  The fact that you have a name on an input item reveals something (however small) about server-side implementation; otherwise, everything would be static or done with ID tags and JavaScript.  Adding brackets a la [] to the end doesn't reveal any more than having a list of identically-named checkboxes, and ensures that those values will always be submitted in an array (instead of having to check for a single value).  It's an extremely minor issue at best, and only particularly relevant to people new to the language.

    One possible way to do this is to not believe the values submitted but simply query the database, retrieve the possible values, then check the submitted data against the database IDs.  That way people can't submit their own IDs (for instance, if there are hidden options).  Then it makes no difference whether it's chosen_1234 or chosen[1234].

  • woah! (unregistered) in reply to CodeRage

    CodeRage:

    And all this for something the browser does for you when it posts the form, had the developer been 1337 enough to give all the checkboxes the same name, with each value being the id.

    Not many people can figure this out.

    Similarly WTFish, in college I had a coworker at a coop job who wrote javascript to submit forms.

    I sat down with him to review a bug, and he was baffled when I fixed it by deleting all the javascript.

    Woah!

  • (cs) in reply to viraptor
    viraptor:
    ammoQ:

    The problem is that if there is excactly one occurrence, it might be just by pure luck, because the user checked one of several checkboxes. The program expects an array and crashes; unfortunately, in PHP, to make things simple, the program cannot tell the HTTP parser if it expects a single occurrence (therefore a simple variable) or an array.

    OMG! Is it that hard to do: (ok - this is WTF - php request processing in php):
    foreach($req as $key => $val) {
        if(!array_key_exists($key, $_GET))
           $_GET[$key]=$val;
        else {
           if(is_array($_GET[$key]))
              $_GET[$key][]=$val;
           else {
              $tmp=$_GET[$key];
              $_GET[$key]=array($tmp, $val);
           }
        }
    }
    It's not a rocket science people...
    Sorry if there's something wrong with code - haven't used php for a while.


    Or... just design your websites so that all the form things have different names... how hard is that?
  • (cs) in reply to UTU
    Anonymous:
    Anonymous:
    PHP apparently discards all but the last value unless the name ends with [], which isn't even legal HTML.


    Umm.. how so? If my memory serves me correctly, "name"-attribute of input-elements is of type CDATA, which means "a sequence of characters from the document character set"... so ending a name with [] is just about as allowed in HTML as ... well, just about anything :)

    I've always been confused by that. Most tags use a CDATA for name, yet there is a defined NAME type:

    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 (".").
  • Anonymous (unregistered) in reply to wyz
    Anonymous:

    The story around it is differenct, or this could be jscript from the place I at now as an on-site contractor!


    Didn't you read the post? The place you're at now obviously bought this code on ebay from the same guy the guy in the post bought it from. Duh!
  • Wombat (unregistered) in reply to AndrewVos
    Anonymous:

    Dare I say "Javascript has the best WTF's" ?

    Somehow it often does :-)

    I had something of a WTF from Javascript yesterday, but I'm going to blame Javascript rather than myself for it.  But I might well be to blame due to my lack of experience with Javascript due to the fact that I avoid it whenever possible.  Yesterday, I was creating a Date object and populating it with data from a form.  Below is a simplified version of what I did:

    var date = new Date();
    date.setYear(2000);
    date.setMonth(1); // 1 for February, since it's zero-based
    date.setDate(10);

    Whenever I set it to February, the outcome would magically be March.  It took a good few minutes of confusion before I figured out what was happening.  The Date contructor was initialising the date to "now" (i.e. yesterday which was 30 August 2006), which is fine because I'm just going to overwrite it anyway.  I set the year to 2000, which was fine.  Then I set the month to February.  But because the day field was already initialised to 30 by the constructor, Javascript thought I was clearly stupid for wanting the 30th of February and changed it to 2nd of March for me behind my back.  Then I set the day to 10, which overwrote half of Javascript's automagic befuddling.  This left it looking like the only thing that had happened was that Javascript was somehow allergic to February.  Of course the potential for this to happen will only happen on the last few days of the month.

    I fixed it with a big table of carefully worked out cases for when to decrement the month after this had happened.  No I didn't because that would have been a real WTF.  I read the docs and realised I should just do:

    var Date = new Date(2000,1,10);
    
  • Thomas (unregistered) in reply to rocksanddirt

    Anonymous:
    As javascript in itself was designed with good intentions,

    Well, as we all know the road to hell is paved with good intentions ...

  • TMLC (unregistered) in reply to Wombat

    One day, someone will implement a date object that makes sence.

    Well, ok, maybe not, but the hope keeps me going.

  • NoTime (unregistered) in reply to powerlord
    powerlord:
    I've always been confused by that. Most tags use a CDATA for name,

    That's because that is how it is defined in the HTML DTD.
    powerlord:
    yet there is a defined NAME type:

    HTML != DTD, so a priori there's no reason to assume that an HTML name is the same thing as a DTD name.
  • blair (unregistered) in reply to NoTime

    <FONT style="BACKGROUND-COLOR: #bfc6d2">No one noticed that the Javascript is commented away? ...</FONT>

  • abc (unregistered) in reply to ammoQ

    ammoQ:
    CodeRage:

    Yeeesh, I'm glad I don't use PHP.  How hard is it to parse the key/value pairs in the http post or get, and then build an array for any key that has more than one occurance...Anyway, thanks to all for clarifying this to me.


    The problem is that if there is excactly one occurrence, it might be just by pure luck, because the user checked one of several checkboxes. The program expects an array and crashes; unfortunately, in PHP, to make things simple, the program cannot tell the HTTP parser if it expects a single occurrence (therefore a simple variable) or an array.
    If the name of the input has [] suffix, it will always be an array, even if only one indice. therefore:

    <input type="checkbox" value="123" name="box[]" />

    ...

    <input type="checkbox" value="456" name="box[]" />

    can always be referenced as:

    <?php

    if (!empty($_GET['array'])) {

        foreach ($_GET['array'] as $array) {

            //do something with $array

        }

    } else {

        //no checkboxes selected.

    }

    ?>

  • (cs)

    Alex Papadimoulis:
    And the previous programmer actually got "in trouble" for trying to sell this proprietary software on eBay.

    Won't Andreas get "in trouble" for trying to post this proprietary software on The Daily WTF?

  • abc (unregistered) in reply to abc

    Well.. that didn't work..

     

    <input type="checkbox" value="123" name="box[]" />

    ...

    <input type="checkbox" value="456" name="box[]" />

    can always be referenced as:

    <?php

    if (!empty($_GET['array'])) {

        foreach ($_GET['array'] as $array) {

            //do something with $array

        }

    } else {

        //no checkboxes selected.

    }

    ?>

  • (cs) in reply to abc
    Anonymous:

    Well.. that didn't work..

     

    <input type="checkbox" value="123" name="box[]" />

    ...

    <input type="checkbox" value="456" name="box[]" />

    can always be referenced as:

    <?php

    if (!empty($_GET['array'])) {

        foreach ($_GET['array'] as $array) {

            //do something with $array

        }

    } else {

        //no checkboxes selected.

    }

    ?>



    wrong names... box<->array
  • abc (unregistered) in reply to ammoQ

    go me.. perhaps I'm the real wtf?

  • SnapShot (unregistered) in reply to Gnictigezoink

    How do you pronounce "TTWTASO"?  It's a great design pattern in need of a better acronym.  I can't wait to start my next project and walk up to the current developers and say: Hi guys I was looking over the code and I got to say this was an excellent use of the TTWTASO design pattern.

  • (cs)

    Check and double-check.

    If this had been in VBScript it wouldn't be a WTF!!

  • (cs) in reply to blair
    Anonymous:

    <FONT style="BACKGROUND-COLOR: #bfc6d2">No one noticed that the Javascript is commented away? ...</FONT>

    That is an HTML comment, to obscure the Javascript from "older" browsers that don't understand JS.

    I assure you the Javascript will be executed (unless JS is disabled by the user on the browser)

  • Bas (unregistered) in reply to blair
    Anonymous:

    <FONT style="BACKGROUND-COLOR: #bfc6d2">No one noticed that the Javascript is commented away? ...</FONT>

    Strangely enough, that's because more browsers will be able to use it then..

  • TheRider (unregistered) in reply to snoofle
    snoofle:
    Anonymous:
    Anonymous:

    Notice the bolded parts.  When the page loads, all the boxes are checked.  If you submit without un-checking and re-checking the box you want, there is no value in the "checkedValues" field.

    Wait, I was wrong.  That doesn't say "checked" it says "on".  This was so stupid I mentally filled in what he should have been doing instead of what he actually did.

    Wow, that's a lot of work to be so wrong.

    Web-neophyte here - I thought check boxes could only be true/false, or possibly [un]checked. "On" ???


    It can also be FileNotFound
  • Me (unregistered) in reply to Wombat
    Anonymous:
    Anonymous:

    Dare I say "Javascript has the best WTF's" ?

    Somehow it often does :-)

    I had something of a WTF from Javascript yesterday, but I'm going to blame Javascript rather than myself for it.  But I might well be to blame due to my lack of experience with Javascript due to the fact that I avoid it whenever possible.  Yesterday, I was creating a Date object and populating it with data from a form.  Below is a simplified version of what I did:

    var date = new Date();
    date.setYear(2000);
    date.setMonth(1); // 1 for February, since it's zero-based
    date.setDate(10);

    Whenever I set it to February, the outcome would magically be March.  It took a good few minutes of confusion before I figured out what was happening.  The Date contructor was initialising the date to "now" (i.e. yesterday which was 30 August 2006), which is fine because I'm just going to overwrite it anyway.  I set the year to 2000, which was fine.  Then I set the month to February.  But because the day field was already initialised to 30 by the constructor, Javascript thought I was clearly stupid for wanting the 30th of February and changed it to 2nd of March for me behind my back.  Then I set the day to 10, which overwrote half of Javascript's automagic befuddling.  This left it looking like the only thing that had happened was that Javascript was somehow allergic to February.  Of course the potential for this to happen will only happen on the last few days of the month.

    I fixed it with a big table of carefully worked out cases for when to decrement the month after this had happened.  No I didn't because that would have been a real WTF.  I read the docs and realised I should just do:

    var Date = new Date(2000,1,10);
    


    Or you could have just set the day before the month.
  • Sofal (unregistered) in reply to powerlord

    One thing I've found very annoying about the whole "name[]" thing that PHP requires is that when you actually do want to access one of these form objects in the JavaScript somewhere you can't just use:

    document.formName.name[]

    Nor can you use (for obvious reasons):

    document.formName.name

    What I eventually had to do was kludgey around it somehow (I can't remember what I did off the top of my head). This is way I think the "name[]" style required by PHP is lame. Anyone have a good way to get around this garbage?

  • Me (unregistered) in reply to Sofal
    Anonymous:
    One thing I've found very annoying about the whole "name[]" thing that PHP requires is that when you actually do want to access one of these form objects in the JavaScript somewhere you can't just use:

    document.formName.name[]

    Nor can you use (for obvious reasons):

    document.formName.name

    What I eventually had to do was kludgey around it somehow (I can't remember what I did off the top of my head). This is way I think the "name[]" style required by PHP is lame. Anyone have a good way to get around this garbage?


    Instead of using $_GET or $_POST, use $_SERVER['argv'] and you should be able to walk through making your own name array.
  • Rich (unregistered) in reply to Sofal
    Anonymous:
    One thing I've found very annoying about the whole "name[]" thing that PHP requires is that when you actually do want to access one of these form objects in the JavaScript somewhere you can't just use:

    document.formName.name[]

    Nor can you use (for obvious reasons):

    document.formName.name

    What I eventually had to do was kludgey around it somehow (I can't remember what I did off the top of my head). This is way I think the "name[]" style required by PHP is lame. Anyone have a good way to get around this garbage?


    document.formName.elements['name'] I believe.
  • Rich (unregistered) in reply to Rich
    Anonymous:

    document.formName.elements['name'] I believe.

    Oops

    document.formName.elements['name[]']
  • JL (unregistered) in reply to Arancaytar
    Arancaytar:
    Hm... so if I got that right, the author of that Javascript didn't trust HTML forms, and instead wrote his own submit-function? Brillant.

    There are cases when you actually might want to do this.  For instance, if you are displaying many rows from a database search in an HTML table, you'd probably want to split the search result across multiple webpages.  Then if you add a checkbox to each row to allow the user to select multiple rows, you need somewhere to store the states of the checkboxes that are on other pages.  If you don't want to store the state on the server, a hidden form field with comma-separated ids works pretty well.  And if you're validating the form input on the server anyway, then it doesn't really matter if you update the checkbox state on the server or the client; with the latter, you'd end up with something pretty similar to this, at least in the generated HTML.

    Of course, that's a lot of "if"s, many of which don't apply here, but the overall design is not unreasonable.  Perhaps the author copied it from another context where it did make sense?
  • Wombat (unregistered) in reply to Me
    Anonymous:
    Anonymous:

     var Date = new Date(2000,1,10); 


    Or you could have just set the day before the month.

    That's the first thing that occurred to me, but it can suffer from the same problem in a slightly different way. 

    For example, if "now" is 10th February and I want to set the date to 30th August: I create the Date with the default constructor and set the day first.  Javascript will think "stupid programmer has specified 30th February, I think that he really means 2nd March (unless it's a leap year in which case it will be 1st March)" and will change the day to 2 rather than 30.  Then I'll set the month to August and the result will be 2nd August.

    Best just to avoid the whole matter by using the other constructor.

  • (cs) in reply to Sofal

    One thing I've found very annoying about the whole "name[]" thing that PHP requires is that when you actually do want to access one of these form objects in the JavaScript somewhere you can't just use:

    How about giving them a unique ID and accessing your elements in a sane way such as:

    document.getElementById('your-unique-name')

    ?

    And object notation is equivalent to hash notation in JS, so you could probably write document.formName['name[]'] as well

  • Sofal (unregistered) in reply to masklinn
    And object notation is equivalent to hash notation in JS, so you could probably write document.formName['name[]'] as well

    Man I didn't even know you could use hash notation like that in JavaScript. Just goes to show how much I know. Thanks!
  • UTU (unregistered) in reply to Sofal
    Anonymous:
    you could probably write document.formName['name[]'] as well

    Man I didn't even know you could use hash notation like that in JavaScript. Just goes to show how much I know. Thanks!


    Please forget you ever heard that. It's so 1990's...
  • White (unregistered) in reply to UTU

    I got a kick out of:

    <FONT color=#ff0000><input class="button" type="button" value="Submit" onclick="submit()" /></FONT>

    and the ...

    <FONT color=#ff0000>function submit()
    {
      document.location.href = 'insert.php?chosen=' +
         document.selecter.checkedValues.value;
      return false;
    }
    </FONT>

    submit() redirects, so it never gets to the return. Better yet, the onclick event never requests a return ... I think the original author may have been thinking of: <form onsubmit="return submit()"> ... like for some validation routine, or something.

    FYI: A checkbox with value="ON" usually occurs, by default, when you drag-n-drop a checkbox object from many graphical HTML designers, like Frontpage, Dreamweaver, etc.

  • DZ-Jay (unregistered) in reply to ammoQ
    ammoQ:
    CodeRage:

    Yeeesh, I'm glad I don't use PHP.  How hard is it to parse the key/value pairs in the http post or get, and then build an array for any key that has more than one occurance...Anyway, thanks to all for clarifying this to me.


    The problem is that if there is excactly one occurrence, it might be just by pure luck, because the user checked one of several checkboxes. The program expects an array and crashes; unfortunately, in PHP, to make things simple, the program cannot tell the HTTP parser if it expects a single occurrence (therefore a simple variable) or an array.


    That seems like a good point.  However, it is pretty easy to work around that issue.  Why not make the accessors to the form data overloaded for both cases?  If the application requests the value from an array, but there is exactly one key with that name, return an array of a single item.  If the application requests the value as a scalar, return it.

    As an added bonus, you could make it return a flatten, comma-separated list of values if there is more than one key with the same name, but the application requested a scalar value.  This is the way some other frameworks work.  Then the intricasies of how the web form is composed or the request is handled, are abstracted from the application developer; while at the same time, the intricasies of how the form is going to be processed by the application, is abstracted from the web designer.

        -dZ.

    --
    Whiskey Tango CAPTCHA
  • DZ-Jay (unregistered) in reply to qbolec
    qbolec:

    Is it just me, or naming all check-boxes "chosen" (or in general in with the same name) is a little bit counter-intuitive? I prefer to think, that check-boxes means items that you want to or don't want to choose, so each of them is separate thing, so I usually name them "choice_0",...,"choice_100", so then you can just perform in  PHP simple scan



    It depends on the context in which the checkboxes are used.  If you have unrelated options such as:

    Program Options:
    [ ] Enable Foo
    [ ] Enable Bar
    [ ] Activate actuator
    [ ] Actuate activator
    [ ] Use the ascension-descension compression tension extension

    Then you may one each to have its own name so that you may treat them individually.  However, if you have a multiple choice list from where the user may check more than one, such as:

    What flavors of ice cream do you like:
    [ ] Mocholate
    [ ] Granilla
    [ ] Fishtachio

    Then you may set them all up with the same name, so that you may treat them as an array of options.

        -dZ.


  • (cs) in reply to DZ-Jay
    DZ-Jay:

    Why not make the accessors to the form data overloaded for both cases?  If the application requests the value from an array, but there is exactly one key with that name, return an array of a single item.  If the application requests the value as a scalar, return it.

    As an added bonus, you could make it return a flatten, comma-separated list of values if there is more than one key with the same name, but the application requested a scalar value.


    IMO a very reasonable proposal. Why doesn't PHP offer that by default? I know, this is one of the unanswerable PHP questions, just like "why does a language especially targeted towards database applications have seperate APIs for each database system?"

Leave a comment on “A New Type of Formation”

Log In or post as a guest

Replying to comment #:

« Return to Article