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. >>>>> >>>>> >>>>> --
