On Jan 3, 12:07 am, mdipierro <[email protected]> wrote:
> On Jan 2, 9:57 am, rctay <[email protected]> wrote:
>
> > On Jan 2, 11:26 pm, mdipierro <[email protected]> wrote:
>
> > > This is a good point but the fact is that
>
> > > db.table.field.requires=[IS_IN_SET(['a','b','c'])]
>
> > > is different from
>
> > > db.table.field.requires=IS_IN_SET(['a','b','c'])
>
> > > Both validate the input in the same way but the latter also make a
> > > select/option dropbox.
>
> > That's true, but in that case, couldn't web2py handle it by looping
> > through and generating the options for a dropbox?
>
> The point is not that it cannot be implemented. The problem is that we
> want to keep the distinction. Some times you want the dropbox (thus
> selecting all records from the db), other times you only want to
> validate the current value (check if it is actually in db). this
> distinction is important because some times you have too many records
> in the drop box ad you want to use other techniques like ajax auto-
> complete but still preserve validation.
pardon me, that didn't occur to me. now i understand, implementing
that would break previous web2py use cases, very bad indeed.
just to clarify, are you saying that using the type of the 'requires'
attribute to control behaviour (ie. validation on one hand and form
input generation on the other) is intended? if that is the case, does
web2py have a more 'formal' way of doing that (eg. through a method or
flag perhaps, IS_IN_SET([...], auto_gen=false) (maybe there is one
that i don't know of; i'm new to web2py))? or are we just stuck with
specifying/not specifiying [...] for 'requires'?
>
> > you could say that allowing lists might lead to the situation where
> > there is more than one validator that provide 'options' attribute',
> > but that's the user's fault. perhaps web2py could warn in such an
> > instance.
>
> > > Moreover doing
>
> > > db.table.field.requires.append(....)
>
> > > assumes that you can append any validator you want and you do not care
> > > about previous validators. This is not the case since validators are
> > > also filters. For example IS_INT_IN_RANGE() converts the input string
> > > to an integer, thus it cannot be piped with validators that expect a
> > > string.
>
> > that's true, however logic in the form validation should handle such
> > cases, because in web2py currently there's nothing stopping you from
> > combining incompatible validators. so, in the situation you raised,
> > currently one could do this:
>
> > db.table.field.requires = [IS_INT_IN_RANGE(), IS_LOWER()]
>
> > but whether it works is a different story, the user shouldn't have
> > done placed two incompatible validators.
>
> > so requires.append-ing an incompatible validator is not a problem, or
> > rather, it isn't a new problem, and it is not a problem that cannot be
> > prevented by the user.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
