I propose that we could add a new "field type" with a name like optional_date. The converter handler for that type could handle an empty field in whatever way we feel is reasonable, without breaking existing applications. (Let the fight over "reasonable" begin! :^)
That's fine by me. And reasonable would be '', since otherwise it really isn't optional. :-) OK, I could accept that None would work too, but '' *has* to work. You can't force end-users to enter magick cookies.
I agree. I'd specify this by saying: o An empty string sent from a browser for an optional_date field is interpreted as a null (not specified) value o The "internal" representation of an optional_date (the value you find in the REQUEST after conversion) is always either a valid DateTime instance or None
I'd also be interested on you take on issue #171, returning empty lists...
I don't have much to add to that thread. It has the same backward-compatibility issue, but I don't perceive it to be as big an issue as the date thing (probably because it can be dealt with in a single line from DTML or Python). Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com