Collector issue #30: Empty dates
http://collector.zope.org/Zope/30 What are people take on empty dates? Today I can find no way to enter empty dates (I think "None" worked before, but it doesn't work in 2.5.1b1 anyway). This is a problem, because we need to be able to have empty dates. Also, enetering something magick (like None, or 1980/0/0 isn't usable. We fix this with this simple patch, which so far has caused us no problems: from ZPublisher import Converters def fixedfield2date(v): from DateTime import DateTime if hasattr(v,'read'): v=v.read() else: v=str(v) if v=='': return v return DateTime(v) Converters.field2date = fixedfield2date Converters.type_converters['date'] = fixedfield2date It's the "if v=='': return v" part that does it. This makes it possible to enter empty strings as dates. We then handle these as unset dates. Seems to work fine as far as we can see. I was told that this had some type of compatibility issue. If thats the case, how do you suggest we fix it? Best Regards Lennart Regebro Torped Strategi och Kommunikation AB
http://collector.zope.org/Zope/30
What are people take on empty dates?
<snip>
This is a problem, because we need to be able to have empty dates. Also, enetering something magick (like None, or 1980/0/0 isn't usable. We fix this with this simple patch, which so far has caused us no problems:
<snip code allowing empty dates>
I was told that this had some type of compatibility issue. If thats the case, how do you suggest we fix it?
This is something that comes up again and again - perhaps we should commit to doing something for Zope 2.6. There are many entries in the Collector with a patch similar to this, that "works for me". The problem is that you are changing a semantic that currently deployed production applications depend on. I, for one, would be quite displeased if the documented behavior I was depending on in my app (raising an error if a valid date was not provided) suddenly changed, probably wreaking havoc on my data integrity. This is the reason why the "change to converters to accept empty dates" has never been accepted. 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! :^) Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
From: "Brian Lloyd" <brian@zope.com>
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'd also be interested on you take on issue #171, returning empty lists...
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
From: "Brian Lloyd" <brian@zope.com>
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 think then the value in the fields will be shown as "None", which I don't particularily like, even though I would rather have None as the internal representation instead of an empty string. Is there a way to fix that, so that date_fields set to None will be displayed as empty?
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).
True, it can wait. We probably need to discuss how all of this should be handled in Zope 3 at some time, because it is a bit confusing today (thanks mostly to the m*r*ns that made the HTML forms specification), and it easy to mix up optional, empty and non-existent. :-) But thats another discussion.
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 think then the value in the fields will be shown as "None", which I don't particularily like, even though I would rather have None as the internal representation instead of an empty string. Is there a way to fix that, so that date_fields set to None will be displayed as empty?
Sure. The property forms just need to do the equivalent of: <dtml-if theDate> <dtml-var theDate fmt="somthing"> </dtml-if> I know that this is a style issue to some, but I feel that the value should either be null or valid, and code and templates should be written to deal with the two possibilities as a matter of course. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
From: "Brian Lloyd" <brian@zope.com>
Sure. The property forms just need to do the equivalent of:
<dtml-if theDate> <dtml-var theDate fmt="somthing"> </dtml-if>
I know that this is a style issue to some
Yeah, it's not the most neat solution. But it works... So, to summarize: The new field type, optional_date accepts empty strings as input which results in the optional_date being set to None. All happy?
participants (2)
-
Brian Lloyd -
Lennart Regebro