I'm not sure I follow. What would an IS_CHECKED validator do? If the purpose is to ensure a box is checked, then you can already use IS_EQUAL_TO(True). But that's not the behavior you were looking for. You wanted the validation to succeed whether or not the box was checked, and the problem there is not with the validator but with the value that is passed to the validator when the box is not checked. It's not clear how a new validator would help here, as such a validator would be completely superfluous.
Anthony On Thursday, December 4, 2014 8:12:17 AM UTC-5, Francisco Ribeiro wrote: > > Anthony, > this is what I'm doing now. I am aware of that, the problem starts on the > interpretation given to the request sent by the browser for checkboxes for > these fields which I thought it should be if it is toggled means True, if > not it means False. I do understand however that for most scenarios the > current interpretation is more useful. The alternative would be to add a > validator called "IS_CHECKED()" to include the distinction missing. > > Thank you, > Francisco > > On Thursday, 4 December 2014 12:30:01 UTC, Anthony wrote: >> >> Note, the problem is not with the validator -- if you pass it the value >> False, it will successfully validate. The issue is that when a checkbox is >> not checked, the browser sends nothing back for that form field (it does >> not send back a value of False), so the value passed to the validator ends >> up being None rather than False. >> >> In your case, just change your code slightly so the validator doesn't get >> assigned in the case of boolean fields. Assuming you have the field type >> stored somehow: >> >> if is_required and type != 'boolean': >> >> Or better yet, just set is_required to False for boolean fields. >> >> Anthony >> >> On Thursday, December 4, 2014 7:00:00 AM UTC-5, Francisco Ribeiro wrote: >>> >>> Kiran, >>> I did not assign the default value of False explicitly but implicitly >>> since it's already the default. >>> >>> Anthony, >>> I understand the interpretation currently in place but if you think >>> about this, validators are supposed to accept allowed values *first* and >>> reject all others. True and False are the allowed values here and must have >>> precedence to be accepted. Checkboxes are UIs for boolean types, so an >>> unticked box means False, it does not mean NULL. >>> >>> On my scenario I have a dynamically generated form using >>> SQLFORM.factory() where one my attributes for each form field is >>> "is_required". So these things are stored on the DB, defining how the form >>> should be generated and the way I was handling it was by adding the >>> IS_NOT_EMPTY() validator to the form field if has the parameter is_required >>> == True on its definition. It works fine for all other input fields tested >>> where IS_NOT_EMPTY() makes sense but checkboxes broke it. >>> >>> Kind regards, >>> Francisco >>> >>> On Thursday, 4 December 2014 11:48:04 UTC, Anthony wrote: >>>> >>>> If a boolean widget can only be true or false and never empty, then >>>> there is no need for this validator to begin with, so just remove it. Are >>>> you suggesting that the validator itself should be changed to always >>>> return >>>> success for booleans? If so, what would be the point? >>>> >>>> Anthony >>> >>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
