Re: [Zope-dev] Collector issue #30: Empty dates
From: Brian Lloyd [EMAIL PROTECTED] 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. ___ 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 )
Re: [Zope-dev] Collector issue #30: Empty dates
From: Brian Lloyd [EMAIL PROTECTED] 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? ___ 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 )
[Zope-dev] 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 ___ 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 )
RE: [Zope-dev] Collector issue #30: Empty dates
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[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 )
Re: [Zope-dev] Collector issue #30: Empty dates
From: Brian Lloyd [EMAIL PROTECTED] 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... ___ 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 )
RE: [Zope-dev] Collector issue #30: Empty dates
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 )
