> > 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        [EMAIL PROTECTED]
V.P. Engineering   540.361.1716       
Zope Corporation   http://www.zope.com

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to