> > 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]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
