This project is archived and is in readonly mode.

#191 ✓invalid
abelda

checkbox inputs with value false

Reported by abelda | July 3rd, 2008 @ 02:08 PM | in 1.2.1

When I send a form, it has checkbox inputs, but they are not checked, these vars are not included in the encoded URI.

I have read this ticket:

Element.toQueryString incorrect behavior

http://mootools.lighthouseapp.co...

It's not the same case, because I think my case is the correct browsers behavior. But I want to know that my form has an checkbox and it is not checked. So:

Current Function:

toQueryString: function(){

....

Element.getSelected(el).map(function(opt){ return opt.value; }) : ((el.type == 'radio' || el.type == 'checkbox') && !el.checked) ? null : el.value;

....

Propososed:

toQueryString: function(){

....

Element.getSelected(el).map(function(opt){ return opt.value; }) : ((el.type == 'radio' || el.type == 'checkbox') && !el.checked) ? 0 : el.value;

....

Comments and changes to this ticket

  • Thomas Aylott

    Thomas Aylott July 11th, 2008 @ 11:57 AM

    • State changed from “new” to “invalid”

    is this a duplicate of #169 ?

  • abelda

    abelda July 11th, 2008 @ 01:01 PM

    Sorry Thomas, but I think its not a duplicate of #169.

    I am talking about checkboxes, and I am proposing another solution.

    In my message I mentioned I have read this thread and I think it is not the same case.

    Could you check it again? Please

    Thanks anyway,

  • Thomas Aylott

    Thomas Aylott July 11th, 2008 @ 10:50 PM

    • Milestone changed from 2.0 to 1.2.1
    • State changed from “invalid” to “open”
    • Tag set to toquerystring

    "my bad" as the kids say.

  • Thomas Aylott

    Thomas Aylott July 11th, 2008 @ 10:55 PM

    • Assigned user changed from “Valerio” to “Thomas Aylott”
  • 131

    131 July 24th, 2008 @ 05:03 PM

    • Title changed from “checkbox inputs with value false” to “This ticket is invalid”

    Unchecked checkbox should not be submited.

    http://www.w3.org/TR/html401/int...

  • 131

    131 July 24th, 2008 @ 05:04 PM

    • Title changed from “This ticket is invalid” to “checkbox inputs with value false”
  • abelda

    abelda July 24th, 2008 @ 11:03 PM

    I have seen that 131 has invalided this thread and has opened it again.

    I just would like to comment that I understand what is an HTML 'Successful control'.

    But in my library (and I think others work like mine), a variable from a form creates an update in my database, whereas an checkbox no checked doesn't send it, and my database is not updated, so I need to see this variable although it is empty.

    Thanks for your time.

  • CroNiX

    CroNiX July 25th, 2008 @ 12:30 AM

    Why can't this be handled serverside?

    In php I use something like this for checkboxes:

    <?php

    $cbox = (!empty($_REQUEST['acheckbox'])) ? $_REQUEST['acheckbox'] : false;

    so $cbox is either whatever value was checked or it is false.

    Im not positive, but I believe it is normal to not send the value if its not checked.

  • abelda

    abelda July 25th, 2008 @ 08:37 AM

    Right CroNiX, but I would like to be able to manage three states: Checked, not checked and not present.

    It's very useful for me, and I think it's easily patched. Even, why don't parameterized it? So, some people could use it, and some people could ignore it.

    Thanks for you comment

  • elado

    elado July 25th, 2008 @ 09:53 AM

    I agree. I had to hack something in my form to have near every checkbox a hidden input and sync between states when checkbox is changed.

    And a real-life sample:

    I have two forms that edit the same entity.

    One is for simple editing and the other is for advanced editing.

    The advanced one contains a checkbox that doesn't appear in the simple one.

    Them both sent to the same handler.

    The handler checks for existence of a value - if it exists, the value is updated, if it doesn't - the value remains the same.

    Now, when the checkbox is not checked on the advanced form, it won't sent. That's an unwanted behavior, since I wanted it to be set to false.

    If I always set the value (true = checked, false = not checked or not sent) than the simple form would always reset it.

  • elado

    elado July 25th, 2008 @ 10:43 AM

    BTW

    The Element::toQueryString method won't send empty input[type=text] even they are successful by W3C. That causes same problem.

  • CroNiX

    CroNiX July 25th, 2008 @ 07:43 PM

    Not to argue the point, but checkboxes by definition are not successful controls if they are not checked. Mootools follows standards, and this is not a standard. It doesn't seem to be a bug to me if its doing what the standard says.

    Here is what the w3c defines as successful form controls:

    http://www.w3.org/TR/html401/int....13.2

    Now as far as getting it to do what you want, you could always extend the class couldn't you?

  • CroNiX

    CroNiX July 25th, 2008 @ 07:46 PM

    or you could override the onsubmit of the form, check the state of the checkboxes, if not checked assign your 'not checked' value.

  • abelda

    abelda July 27th, 2008 @ 10:38 PM

    Of course [again] CroNiX, but I insist [again].

    I would prefer to extend the Element::toQueryString method than override the onsubmit form event. I have always overrrided it, until I stated to use MooTools.

    I have just proposed this 'patch' because:

    • I think I am not the only one who use to override onsubmit for this reason. At least Devign is in my team.
    • It is very very easy to improve it. 25 characters?
    • And OK I could extend my class, I have done it, but it's my tiny contribution to this great project.

    Good night.

  • 131

    131 July 28th, 2008 @ 08:36 AM

    You don't get it.

    It's not because it's a super-light and efficient improvement we should accept it.

    It's because it's a very Bad Thing to overide standarts here.

    Imagine something like

    User : John / Id : 14 / [input checkbox name='check[14]'/]

    User : Tom / Id : 13 / [input checkbox name='check[13]'/]

    User : Kate / Id : 22 / [input checkbox name='check[22]'/]

    For the current selection :

    [input name=action value=selection_delete/]

    [?

    //i follow the standart, i cannot have ANY problem here

    if($_POST['action']=='selection_delete'){

    foreach(array_keys($_POST['check']) as $user_id_to_delete)

    users::delete($user_id_to_delete);

    }

    There're not good reason we go against standarts here.

    But since mootools is build this way, that's not an issue at all, just over-write element.toQueryString with your own definition in your mootools.patch.mine.js

    That's the right way to do.

    This ticket is nothing more than a request to go against a well defined and spreaded standard, sorry

  • abelda

    abelda July 28th, 2008 @ 08:48 AM

    I'm sorry 131, but I think your sample, is a bad sample. Just because it would be solved with a simple 'if' into your foreach.

    Anyway. As you (and CroNiX) say, I can have my 'mootools.patch.mine.js' extension, and I have it.

    Thanks indeed for your point of view, and your time to listen mine.

  • elado

    elado July 28th, 2008 @ 08:55 AM

    131, I agree we should not go against standards.

    The current state of the method is not standard, as empty input[type=text] won't be sent even it's successful, so this should be fixed...

    As for the checkboxes, I've done this patch that sends them within my patch file.

  • abelda

    abelda July 28th, 2008 @ 09:08 AM

    Devign : "131, I agree we should not go against standards."

    Which prove in fact, we are not Microsoft.

    Devign : "The current state of the method is not standard, as empty input[type=text] won't be sent even it's successful, so this should be fixed..."

    Really. I have patched it too.

    Devign : "As for the checkboxes, I've done this patch that sends them within my patch file"

    As I said, Devign is in my team :)

  • elado

    elado July 28th, 2008 @ 09:19 AM

    Even though, I don't think W3C were right by defining unchecked checkbox as unsuccessful input. It should've act like empty input text. Maybe they wanted to save traffic, which becomes less relevant these days.

  • 131

    131 July 28th, 2008 @ 09:52 AM

    BTW, my input[type=text] is patched ( in mootools.patch.mine.js )

  • Thomas Aylott

    Thomas Aylott July 28th, 2008 @ 12:15 PM

    The bug with text inputs is a separate bug and has been fixed in

    github. The next minor update will gave that fixed.

    See #169 iirc

    --

    Thomas Aylott / SubtleGradient (from iPhone)

    On Jul 28, 2008, at 4:52 AM, Lighthouse

    wrote:

  • Thomas Aylott

    Thomas Aylott July 28th, 2008 @ 12:18 PM

    • State changed from “open” to “invalid”
    • Tag changed from toquerystring to checkbox, toquerystring

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

Pages