Simulate click() for jQuery Validation

[decadeofdefeat]

I noticed when I'm using jQuery form Validation (http://jqueryvalidation.org/) that the form does validate correctly if the radio button is required, but the error label doesn't disappear after you click the prettyCheckable radio button. That's because the validation class is waiting for a click function on the real radio button to update the errors.

So I updated the prettyCheckable.js to add a click() function to the input.

    if (input.prop('checked')) {
          input.prop('checked', false).change();
          input.click();

      } else {
          input.prop('checked', true).change();
          input.click();

      }

So please update your source to resolve this issue.

[arthurgouveia]

This code will break the plugin because once you click it, it will go through the function and check if it is either checked or not and trigger the change event.

If you trigger a click on the input, it will change the state of the hidden input, so you would end up with a style anchor tag showing the input was checked when in fact it is not.

Try using this code of yours and setting display: block to the hidden input. You should be able to see what I'm trying to explain.

[decadeofdefeat]

It's not breaking the plugin for me. The validation works if I didn't click a radio button when its required, and when I click the prettyCheckable radio button the error message now disappears, and the POST results are still correct.

See my example below with the real radio button set to display:block
http://www.markgoldsmith.me/testbed/form/

[Ryan-YJL]

It worked for me as I needed to listen to a click event on the radio input to do some ajax post. Thanks @decadeofdefeat

[ventureio]

Oi Arthur, I was investigating the same issue for hours and this suggested addition fixed my problem. I'm doing both jquery and validation off input change/click events, but this very cool plugin wasn't working at all for me without something like this. I haven't tested this change thoroughly, but I would be happy to test any official effort or help in anyway to implement this behavior for good. I'll also donate either way once I'm sure this change will fix the problem for me, as this is exactly what I'm looking for.

Toward that end, I'm not sure I follow what you mean by "end up with a style anchor tag showing the input was checked when in fact it is not". That doesn't seem to be happening, or maybe I'm missing the obvious. In any case is there a way to implement this behavior so it is compatible? WDYT?

Muito obrigado -- Jaden

[chriscalip]

nevermind. doing a pivot..

[decadeofdefeat]

I just confirmed using input.click(); does break the POST variables for checkboxes. I have no clue why. Since validation is pretty important to me, I suppose I just won't use prettyCheckable anymore.

[arthurgouveia]

I'm gonna have to get some time to check it all over again. Aside, I'll also need to write proper Jasmine tests.

Unfortunately I don't have enough spare time to solve all issues I see here or merge pull requests that don't have written tests.

Meanwhile, you're all welcome to help everyone out by doing so.

I haven't tested this:

input.prop('checked', false).change();
input.click();

But what I see here is that the .prop checked will be set to true/false, there will be a trigger for "change" on the input and then, a click() event would happen, triggering another time the event and therefore invalidating stuff.

[arthurgouveia]

I see for @decadeofdefeat test url that apparently it does not break anything since the .click event is triggered on the input itself, and prettyCheckable does not listen for clicks on the input, but on the anchor tag and label.

Can someone make sure it works out like that? A test would be much appreciated on the gh-pages branch.

[arthurgouveia]

Guys, here it is, as I suspected: http://jsfiddle.net/r5enb/

If you add a call to input.click() after checking the input, it will check it twice, resulting in the same state you see at first.

The check action consists into setting the prop 'checked' and attribute 'checked' to boolean values and triggering a change event in case you added a listener do the input.

On the example, you'll see that if I add a call to .click() after setting prop and attr, it will trigger a change event twice and the checkbox won't have it's state changed. Remove the .click() call and it will work as expected.

@decadeofdefeat would you be able to add the validation on the input for it's checked state instead of listening to a click?

@venturepilot wanna test it out?

[ventureio]

Hey Arthur,

When I commented on this issue I was really psyc'd to use checkable, but
after fooling around with this issue for too long I moved on and just used
BS style glyphs. I would love to help you out but it has been too long ago
and the client system is long gone from my project plate, so I'm not sure
where I would start to test the issue I was having at the time.

I'd be happy to test your implementation from a QA standpoint to see if
your solution works for your needs for usability?

Cheers,

Jaden

On Fri, May 9, 2014 at 2:39 PM, Arthur Gouveia [email protected]:

Guys, here it is, as I suspected: http://jsfiddle.net/r5enb/

If you add a call to input.click() after checking the input, it will check
it twice, resulting in the same state you see at first.

The check action consists into setting the prop 'checked' and attribute
'checked' to boolean values and triggering a change event in case you added
a listener do the input.

On the example, you'll see that if I add a call to .click() after setting
prop and attr, it will trigger a change event twice and the checkbox won't
have it's state changed. Remove the .click() call and it will work as
expected.

@decadeofdefeat https://github.com/decadeofdefeat would you be able to
add the validation on the input for it's checked state instead of listening
to a click?

@venturepilot https://github.com/venturepilot wanna test it out?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-42705407
.

[arthurgouveia]

Fuck me. Sorry. I haven't had much time to work on this. I got a small window today and that's why I've been replying to everyone.

If you're willing to help out the project, check the code as it is ATM, check the proposed solutions and see if the example I built states my concerns.

[ventureio]

Oi Arthur!

Didn't realize you were the lead on this project :-) And please don't
apologize, your contribution is awesome regardless if life gets in the way
a lot.

I'll try to find some time this weekend or next week to review what my
issue was before and see if the new code suggestion resolves it.

Cheers,

Jaden

On Fri, May 9, 2014 at 2:49 PM, Arthur Gouveia [email protected]:

Fuck me. Sorry. I haven't had much time to work on this. I got a small
window today and that's why I've been replying to everyone.

If you're willing to help out the project, check the code as it is ATM,
check the proposed solutions and see if the example I built states my
concerns.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-42706395
.