You can do
db.table.filter_in = lambda value: 'NT' is value is None else value
On Saturday, 27 October 2012 02:54:53 UTC-5, Joe Barnhart wrote:
>
> But Paolo -- you forgot the third option...
>
> FIX the problem in dal.py so that Validator classes work properly. It has
> no deleterious effects on other validators (at least so far in my testing)
> and it permits validators to format None values.
>
> -- Joe B.
>
>
> On Friday, October 26, 2012 9:56:57 AM UTC-7, Paolo Caruccio wrote:
>>
>> In my opinion, you have mainly two options to bypass None value check
>> that formatter function in DAL does:
>>
>> option 1 : store None in database, delete formatter from validator, use
>> represent in table field (I prefer this approach)
>>
>> class IS_ELAPSED_TIME(object):
>> def __init__(self,error_message='Must be MM:SS.hh or MMSShh (with no
>> punctuation)'):
>> self.error_message=error_message
>> def __call__(self,value):
>> try:
>> if value and value.upper() != 'NT':
>> res = hms_to_int(value)
>> else:
>> res = None
>> return (res,None)
>> except:
>> return (value,self.error_message)
>>
>>
>> Field('est', 'string', requires=IS_ELAPSED_TIME(), represent=lambda value
>> ,row:int_to_hms(value) if value else "NT")
>>
>>
>> option 2: store 'NT' in database in place of None
>>
>> class IS_ELAPSED_TIME(object):
>> def __init__(self,error_message='Must be MM:SS.hh or MMSShh (with no
>> punctuation)'):
>> self.error_message=error_message
>> def __call__(self,value):
>> try:
>> if value and value.upper() != 'NT':
>> res = hms_to_int(value)
>> else:
>> res = 'NT'
>> return (res,None)
>> except:
>> return (value,self.error_message)
>> def formatter(self,value):
>> if value != 'NT':
>> rtn = int_to_hms(value)
>> else:
>> rtn = 'Elapsed Standard Time not available'
>> return rtn
>>
>>
>> Field('est', 'string', requires=IS_ELAPSED_TIME())
>>
>>
>>
>> Il giorno venerdì 26 ottobre 2012 04:13:55 UTC+2, Joe Barnhart ha scritto:
>>>
>>> I do manage the "None" value in my formatter, Paulo.
>>>
>>> But it never gets called because the built-in code of the Field class
>>> tests the value for None and then exits before calling my formatter. So it
>>> doesn't matter that my formatter can handle None -- it is never called.
>>>
>>> That's why I posted the change to the Field class in the first message
>>> of this thread.
>>>
>>> -- Joe B.
>>>
>>> On Thursday, October 25, 2012 5:53:43 PM UTC-7, Paolo Caruccio wrote:
>>>>
>>>> Why don't you manage None values in int_to_hms function?
>>>>
>>>>
>>>> Il giorno giovedì 25 ottobre 2012 03:20:29 UTC+2, Joe Barnhart ha
>>>>>>> scritto:
>>>>>>>>
>>>>>>>> I have an application where I expect "None" items in my database
>>>>>>>> and I want to format them to "NT". It is an app that uses time
>>>>>>>> standards,
>>>>>>>> and if there is no standard present I expect a "None" in the database
>>>>>>>> which
>>>>>>>> translates to a field of "No Time" or "NT".
>>>>>>>>
>>>>>>>> The problem is that the current implementation of formatter in the
>>>>>>>> Field class tests the value for "None" and escapes before the
>>>>>>>> formatter is
>>>>>>>> called.
>>>>>>>>
>>>>>>>> I can see why this behavior might be expected in a lot of cases,
>>>>>>>> but it seems extreme to deny the ability to format "None" into a more
>>>>>>>> pleasing form for those applications that could benefit from it. Here
>>>>>>>> is
>>>>>>>> the offending part of formatter (located in gluon/dal.py):
>>>>>>>>
>>>>>>>> def formatter(self, value):
>>>>>>>> requires = self.requires
>>>>>>>> if value is None or not requires:
>>>>>>>> return value
>>>>>>>>
>>>>>>>> If I change the above to:
>>>>>>>>
>>>>>>>> def formatter(self, value):
>>>>>>>> requires = self.requires
>>>>>>>> if not requires:
>>>>>>>> return value
>>>>>>>>
>>>>>>>> I get my desired behavior, which is to pass "None" to my formatter
>>>>>>>> which is implemented as part of a custom Validator object. I realize
>>>>>>>> the
>>>>>>>> code now has to go "further" for cases where the value is None, but is
>>>>>>>> it
>>>>>>>> really safe to assume nobody will ever want to "format" None into
>>>>>>>> another
>>>>>>>> string? Not in my case, at least!
>>>>>>>>
>>>>>>>> Joe B.
>>>>>>>>
>>>>>>>>
>>>>>>>>
--
