>
> Ah I see now where that behavior is mentioned. Is the _and argument valid
>> for all validators, or just IS_IN_DB?
>>
>
Just IS_IN_DB. I think the only other one for which it might be relevant is
IS_IN_SET, but once you specify a specific set of items, you generally
wouldn't need to apply additional validators. Also, note that whether or
not you get the drop-down widget for IS_IN_DB and IS_IN_SET is just default
behavior -- you can always explicitly specify the widget for a given field:
Field('myfield', requires=[IS_IN_SET(['a', 'b', 'c']),
some_other_validators], widget=SQLFORM.widgets.options.widget)
Above, you still get the dropdown even though IS_IN_SET is in a list of
validators.
> Seems that that would solve my problem. Side note, it seems like this
>> feature of adding a validator to a list to remove the drop-down box should
>> be a validator construction argument all on its own, it seems kind of
>> random to attach that behavior to adding a validator to a list. Just imo.
>>
>
Perhaps we could add an argument to remove the dropdown, but we would also
have to retain the current behavior for backward compatibility.
> Now that I think about it, it's possible this problem actually has to do
>>> with the CAS system I'm using to authenticate; user info isn't being pulled
>>> across upon verification, so I wanted to have the user info fields computed
>>> with a function that pulls in data from an LDAP service. However, this
>>> didn't work, so I had to explicitly call a method at some point in my model
>>> code. Now that I think about it, it's possible the compute functions
>>> weren't being called because the auth subsystem was actually providing
>>> values for those info fields, albeit NULL values. Is that the expected
>>> behavior of the DAL, to not call compute on a field if NULL is explicitly
>>> passed to its column on insert?
>>>
>>
That's right -- the compute function will only be called if the compute
field is completely absent from the insert/update call.
Anthony
