[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Godefroid Chapelle wrote: > yuppie wrote: > > > >> AFAICS, KSS will no longer need the monkey patch if it sets the >> LookupClass to FiveVerifyingAdapterLookup. >> > I tried to test your code this evening... > > This implied starting to fix Archetypes and Plone to work with all the > changes made in CFMCore.interfaces I backported all the changes and adjusted it accordingly, so you can test the code against Plone without adjusting Plone to CMF trunk. Beware that there still seem to be some general issues. As noted on the other mail, all integration tests currently fail :( But help in fixing those is most welcome ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Hi. Martin Aspeli wrote: > Hi Yuppie, > >> This proposal is now implemented on CMF and five.localsitemanager >> trunk. Everything *seems* to work, but maybe I'm missing something. >> This might be a good time to review and test the changes - any >> feedback is welcome. > > Well done - great work! :) > >> Done: >> - >> >> There are 10 tools in CMF that are not ready for being used as >> utilities, they have to be used the old way until they are fixed: >> >> content_type_registry >> cookie_authentication >> portal_actions >> portal_calendar >> portal_catalog >> portal_skins >> portal_types >> portal_uidhandler >> portal_url >> portal_workflow > > Are these registered as utilities as all? Or only available using > getToolByName? They are not utilities, so they are not registered as ones. Only available through good old getToolByName :) >> ToDo: >> - >> >> - real world testing My testing of Plone 3.0 after the merge so far results in all integration tests failing with that stupid error inside the component registry when it throws an AttributeError on 'adapters'. The error happened a few times already, but I'm too tired to figure out right now why it is failing this time. >> - backport to the CMF 2.1 branch > > Is this in the pipeline? i.e. will this code land in Plone 3.0? :-) I just did the backport. One test fails in pure CMF 2.1. I was so evil and commented it out. The test is in CMFCore/test/test_SkinsTool and is named test_getCurrentSkinName. I marked it with a XXX comment. Yvo could you look at it, I didn't quite understand all the skins related changes? >> - fix the GenericSetup handler > > How so? There's not only an open bug report in the CMF collector, but I also still have a mail in my inbox with all the changes we agreed on a while back... once the latest changes have proven to be stable, I'll get right to it. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Hi Yuppie, This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Well done - great work! :) Done: - There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow Are these registered as utilities as all? Or only available using getToolByName? These 15 CMF tools are registered as utilities, AFAICS only the security machinery uses their acquisition context (except for portal_membership, which uses 'self.acl_users'): Products.CMFActionIcons.interfaces.IActionIconsTool Products.CMFCore.interfaces.ICachingPolicyManager Products.CMFCore.interfaces.IDiscussionTool Products.CMFCore.interfaces.IMemberDataTool Products.CMFCore.interfaces.IMembershipTool Products.CMFCore.interfaces.IMetadataTool Products.CMFCore.interfaces.IPropertiesTool Products.CMFCore.interfaces.IRegistrationTool Products.CMFCore.interfaces.ISiteRoot Products.CMFCore.interfaces.ISyndicationTool Products.CMFCore.interfaces.IUndoTool Products.CMFUid.interfaces.IUniqueIdAnnotationManagement Products.CMFUid.interfaces.IUniqueIdGenerator Products.GenericSetup.interfaces.ISetupTool Products.MailHost.interfaces.IMailHost five.localsitemanager now returns wrapped utilities without RequestContainers. This requires a new LookupClass. Interesting. Do we still get deprecation warnings if these are looked up using getToolByName? My feeling is that we should *not* get deprecating warnings for these. It's rather late in the day for this release to officially deprecate such fundamental parts of CMF, and I fear that people won't be able to remember which tools are now utilities and which ones are tools, since the distinction really comes down to implementation detail. Hopefully, the path forward is that *all* the tools become utilities (your last to-do below). In that case, I think full deprecation of lookup via getToolByName makes sense, since we have a uniform API (getUtility()) for looking up CMF's fundamental components. Until then, I think we should give people the choice on the utilities we still have, but not prod them too hard. ToDo: - - real world testing - backport to the CMF 2.1 branch Is this in the pipeline? i.e. will this code land in Plone 3.0? :-) - write migration code for CMF 2.1 beta sites that replaces the LookupClass and removes some utility registrations Plone will likely need the same migrations. - fix the GenericSetup handler How so? - figure out if we can make acl_users an utility Spooky... - in the long run, modify all tools to make them work as utilities Yes - as per above, I think this needs to be the ultimate goal. AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. Great - this is really wonderful news. Martin -- Acquisition is a jealous mistress ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
yuppie wrote: Hi! This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Thanks ! AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. Cheers, Yuppie I tried to test your code this evening... This implied starting to fix Archetypes and Plone to work with all the changes made in CFMCore.interfaces I must say I stopped when I found out IExtensibleMetadata is now a Z3 interface where code in Archetypes still awaits it to be a Z2 interface. I am ready to move on if someone can tell me the pattern to migrate calls like if not IExtensibleMetadata.isImplementedByInstancesOf(klass) interface I currently do not know the dance to move from Z2 to Z3 interfaces. However, I wonder if all the changes needed to run Plone 3 above CMF/trunk won't avoid us to actually test the new code... -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Re: Effective Date inconsistencies
On Sat, 23 Jun 2007 04:34:37 -0700, Charlie Clark <[EMAIL PROTECTED]> wrote: If it returns a __FLOOR_DATE then you can easily write your own comparison to create a boolean. has an effective date and was modified afterwards Wonderful, then my template code depends on some variable defined in the code as the floor date as a private variable, meaning I shouldn't introspect it. Very robust. ;) -- Alexander Limi · http://limi.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Re: Effective Date inconsistencies
On Sat, 23 Jun 2007 08:15:02 -0700, Wichert Akkerman <[EMAIL PROTECTED]> wrote: Previously Laurence Rowe wrote: How about changing EffectiveDate to: return ed and ed.toZone(zone).ISO() or '' from the existing (as pointed out by Charlie): return ed and ed.toZone(zone).ISO() or 'None' It would seem the least risky fix. (I'm not sure it's strictly a bug but it struck me as completely brain dead when I was caught out by it). We can't change it - people may rely on the current behaviour. Which I why I ask here, people that may rely on this are likely to be on this list (and able to speak up about it). The fact that zope.dublincore got it right makes it even more interesting to harmonize them, IMO. -- Alexander Limi · http://limi.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: state of GenericSetup trunk and branches
On 6/22/07, Rob Miller <[EMAIL PROTECTED]> wrote: > Well. I'd prefer to have *one* obvious and explicit solution. The > failover adds extra code that needs to be maintained and makes it less > obvious where the version number comes from. i agree. i was thinking since my last reply that, since the code is already in there, we could support a special value in the metadata.xml file that explicitly tells GS to use the product version for the profile version, rather than having that be the default behaviour. I think that the profile version number typically should *not* be the same as the version number. Quite often you make a release without changing anything in the profile, and profiles may be just configuration and then not have anything to do with any product version. So I'd prefer if profile versions just aren't product versions at all. But it's not a strong opinion. > If it is pure registration information, why don't we extend the ZCML > directive? But AFAICS data like the version number belongs to the > profile itself and it might be useful to add timestamp based version > numbers to exported profiles. Sounds reasonable to me. All in all, btw, these new feature to GenericSetup look bitchin', and will make truly awseome! :-) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: state of GenericSetup trunk and branches
Maurits van Rees, on 2007-06-23:
> 2. What needs to happen on the import tab now on trunk? We want a
>drop down that lists all extension profiles. When I select one of
>those extension profiles, should I get a list of only those steps
>for which this profile has an xml file?
This does not seem possible, unless we add more info about steps to
the registry: the name of the xml file that the handler of that step
will read.
>Or should I just get a
>list of all steps available (several dozen on Plone 3) and have the
>extension profile as context when I click the correct button?
I added that. I have no commit rights, so for the total changes
(including the previous one for the Profiles tab), see here:
http://paste.plone.org/15349
Just select your favorite extension profile, perhaps select some steps
and then click the Import selected/all button.
The tests still pass, but I did not add extra tests. The current
manage_* methods from the setup tool are also not tested, so I do not
feel very guilty. ;-)
One thing that we may want to do differently: with this code it is
possible to create a new Zope and Plone site, go to portal_setup, go
to the Import tab *without* going to the Profiles tab first, select
the eXtremeManagement extension profile (if you have that in your
Products dir) and run all steps. Then all steps get run, except the
importVarious step, as that has not been registered yet. Wait, that
does not actually happen. The importVarious step gets run after all.
Maybe it now gets registered on the fly in some part of the code. Oh
well.
One other thing that strikes me as odd: I added a few lines in my
setuphandler like:
logger.info("Migrated schema of %s", contentType)
In the event log this correctly gives lines like this:
INFO GenericSetup.eXtremeManagement Migrated schema of eXtremeManagement.Task
But the message log on the import tab gives me lines like this:
eXtremeManagement: Migrated schema of %s
So the argument is lost somewhere.
>As a test I added my own eXtremeManagement product in the Products
>dir, which also has a GS extension profile with an importVarious
>step. I registered this profile with the patch I linked to above.
>Then I tried to import all steps. This meant that the
>eXtremeManagement importVarious step was run, which gave problems
>as it assumed some portal types to be available, which were not
>there. I now fixed that by checking what the context is:
>
> def importVarious(context):
> if 'Products/eXtremeManagement/profiles/default' \
> not in context._profile_path:
> return
> ...
I now changed that to:
if not context._profile_path.startswith(os.path.split(__file__)[0]):
logger.info('Nothing to import: not in eXtremeManagement path')
return
I see that some other products (Plone, CMFEditions) use a different
strategy:
# Only run step if a flag file is present
if context.readDataFile('cmfeditions_various.txt') is None:
return
So they add a simple text file to their profile directory and if that
does not exist in the current import context, then the importVarious
function quits. Works too.
Any thoughts on which of the two strategies is better?
Hm, I just selected my importVarious step and ran that step with its
dependencies, but I did that with the base (Plone) profile. This step
has three dependencies. These dependencies are imported (but with the
xml files from Plone as their data) and then the importVarious step
itself exits early because of the check I added:
INFO GenericSetup.propertiestool Properties tool imported.
INFO GenericSetup.catalog Catalog imported.
INFO GenericSetup.workflow Workflow tool imported.
INFO GenericSetup.eXtremeManagement Nothing to import: not in eXtremeManagement
path
So the dependencies are run, but then the code in the depending step
realizes it does not actually need to run itself, so running the
dependencies was not really needed. I understand what is happening,
but it sounds a bit wrong to me.
--
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
"Do not worry about your difficulties in computers,
I can assure you mine are still greater."
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Effective Date inconsistencies
Previously Laurence Rowe wrote:
> Maurits van Rees wrote:
> >Wichert Akkerman, on 2007-06-23:
> >>Previously Maurits van Rees wrote:
> >>>Wichert Akkerman, on 2007-06-23:
> I misread the interface; that only specified what should happen if no
> timezone is given. The interface says that the method should return a
> string which corresponds to the time or None if no time is set. So the
> behaviour you see is expected and can not be changed without breaking
> backwards compatibility.
> >>>Where are you reading that? Products.CMFCore.interfaces.IDublinCore
> >>>only has some comments:
> >>Look at what interfaces/__init__.py does: it imports the interface from
> >>_content.py. DublinCore.py is a bbb stub.
> >
> >Ah, there. :)
> >
> >But that interface says:
> >
> > Result is a string, formatted '-MM-DD H24:MN:SS TZ', or None.
> >
> >I parse that as:
> >
> > Result is (a string, formatted '-MM-DD H24:MN:SS TZ',) or None.
> >
> >and not as:
> >
> > Result is a string, formatted ('-MM-DD H24:MN:SS TZ' or 'None').
> >
> >Put simpler, I parse that as:
> >
> > Result is a string or None.
> >
> >which seems just what Limi wants.
> >
> >In zope.dublincore that I quoted, the idea was that the result is a
> >formatted string or an empty string. In other words, there it is
> >always a string, though it may be empty. At least the boolean values
> >of the empty string and None are the same: False, as opposed to
> >bool('None') which is True.
> >
> >I am not sure where I am going with this line of reasoning :) but it
> >seems to me the zope.dublincore interface is slightly preferable,
> >always returning a string and still giving a good boolean value.
> >
>
> How about changing EffectiveDate to:
>
> return ed and ed.toZone(zone).ISO() or ''
>
> from the existing (as pointed out by Charlie):
>
> return ed and ed.toZone(zone).ISO() or 'None'
>
> It would seem the least risky fix. (I'm not sure it's strictly a bug but
> it struck me as completely brain dead when I was caught out by it).
We can't change it - people may rely on the current behaviour.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Effective Date inconsistencies
Maurits van Rees wrote:
Wichert Akkerman, on 2007-06-23:
Previously Maurits van Rees wrote:
Wichert Akkerman, on 2007-06-23:
I misread the interface; that only specified what should happen if no
timezone is given. The interface says that the method should return a
string which corresponds to the time or None if no time is set. So the
behaviour you see is expected and can not be changed without breaking
backwards compatibility.
Where are you reading that? Products.CMFCore.interfaces.IDublinCore
only has some comments:
Look at what interfaces/__init__.py does: it imports the interface from
_content.py. DublinCore.py is a bbb stub.
Ah, there. :)
But that interface says:
Result is a string, formatted '-MM-DD H24:MN:SS TZ', or None.
I parse that as:
Result is (a string, formatted '-MM-DD H24:MN:SS TZ',) or None.
and not as:
Result is a string, formatted ('-MM-DD H24:MN:SS TZ' or 'None').
Put simpler, I parse that as:
Result is a string or None.
which seems just what Limi wants.
In zope.dublincore that I quoted, the idea was that the result is a
formatted string or an empty string. In other words, there it is
always a string, though it may be empty. At least the boolean values
of the empty string and None are the same: False, as opposed to
bool('None') which is True.
I am not sure where I am going with this line of reasoning :) but it
seems to me the zope.dublincore interface is slightly preferable,
always returning a string and still giving a good boolean value.
How about changing EffectiveDate to:
return ed and ed.toZone(zone).ISO() or ''
from the existing (as pointed out by Charlie):
return ed and ed.toZone(zone).ISO() or 'None'
It would seem the least risky fix. (I'm not sure it's strictly a bug but
it struck me as completely brain dead when I was caught out by it).
Laurence
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Effective Date inconsistencies
Wichert Akkerman, on 2007-06-23:
> Previously Maurits van Rees wrote:
>> Wichert Akkerman, on 2007-06-23:
>> > I misread the interface; that only specified what should happen if no
>> > timezone is given. The interface says that the method should return a
>> > string which corresponds to the time or None if no time is set. So the
>> > behaviour you see is expected and can not be changed without breaking
>> > backwards compatibility.
>>
>> Where are you reading that? Products.CMFCore.interfaces.IDublinCore
>> only has some comments:
>
> Look at what interfaces/__init__.py does: it imports the interface from
> _content.py. DublinCore.py is a bbb stub.
Ah, there. :)
But that interface says:
Result is a string, formatted '-MM-DD H24:MN:SS TZ', or None.
I parse that as:
Result is (a string, formatted '-MM-DD H24:MN:SS TZ',) or None.
and not as:
Result is a string, formatted ('-MM-DD H24:MN:SS TZ' or 'None').
Put simpler, I parse that as:
Result is a string or None.
which seems just what Limi wants.
In zope.dublincore that I quoted, the idea was that the result is a
formatted string or an empty string. In other words, there it is
always a string, though it may be empty. At least the boolean values
of the empty string and None are the same: False, as opposed to
bool('None') which is True.
I am not sure where I am going with this line of reasoning :) but it
seems to me the zope.dublincore interface is slightly preferable,
always returning a string and still giving a good boolean value.
--
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
"Do not worry about your difficulties in computers,
I can assure you mine are still greater."
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Effective Date inconsistencies
Previously Maurits van Rees wrote: > Wichert Akkerman, on 2007-06-23: > > Previously Wichert Akkerman wrote: > >> Previously Alexander Limi wrote: > >> > Not so: > >> > > >> > - EffectiveDate returns a *string* 'None' when it has no value (wtf?) > >> > >> That is wrong: it should return 'the time in the system default > >> timezone' as documented in T Products.CMFCore.interfaces.IDublinCore. > > > > I misread the interface; that only specified what should happen if no > > timezone is given. The interface says that the method should return a > > string which corresponds to the time or None if no time is set. So the > > behaviour you see is expected and can not be changed without breaking > > backwards compatibility. > > Where are you reading that? Products.CMFCore.interfaces.IDublinCore > only has some comments: Look at what interfaces/__init__.py does: it imports the interface from _content.py. DublincCore.py is a bbb stub. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Effective Date inconsistencies
Wichert Akkerman, on 2007-06-23: > Previously Wichert Akkerman wrote: >> Previously Alexander Limi wrote: >> > Not so: >> > >> > - EffectiveDate returns a *string* 'None' when it has no value (wtf?) >> >> That is wrong: it should return 'the time in the system default >> timezone' as documented in T Products.CMFCore.interfaces.IDublinCore. > > I misread the interface; that only specified what should happen if no > timezone is given. The interface says that the method should return a > string which corresponds to the time or None if no time is set. So the > behaviour you see is expected and can not be changed without breaking > backwards compatibility. Where are you reading that? Products.CMFCore.interfaces.IDublinCore only has some comments: # BBB: module will be removed in CMF 2.2 # zope2 interfaces created on runtime: # - DublinCore # - CatalogableDublinCore # - MutableDublinCore In zope(.app).dublincore.interfaces I see class ICMFDublinCore(Interface): ... def EffectiveDate(): """Return the effective date The value of the first Dublin Core `Date` element qualified by 'effective' is returned as a unicode string if a qualified element is defined, otherwise, an empty unicode string is returned. The string is formatted '-MM-DD H24:MN:SS TZ'. "" So: either it returns a nicely formatted string with a date or it returns an empty string, but not 'None'. -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ "Do not worry about your difficulties in computers, I can assure you mine are still greater." ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Hi! This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Done: - There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow These 15 CMF tools are registered as utilities, AFAICS only the security machinery uses their acquisition context (except for portal_membership, which uses 'self.acl_users'): Products.CMFActionIcons.interfaces.IActionIconsTool Products.CMFCore.interfaces.ICachingPolicyManager Products.CMFCore.interfaces.IDiscussionTool Products.CMFCore.interfaces.IMemberDataTool Products.CMFCore.interfaces.IMembershipTool Products.CMFCore.interfaces.IMetadataTool Products.CMFCore.interfaces.IPropertiesTool Products.CMFCore.interfaces.IRegistrationTool Products.CMFCore.interfaces.ISiteRoot Products.CMFCore.interfaces.ISyndicationTool Products.CMFCore.interfaces.IUndoTool Products.CMFUid.interfaces.IUniqueIdAnnotationManagement Products.CMFUid.interfaces.IUniqueIdGenerator Products.GenericSetup.interfaces.ISetupTool Products.MailHost.interfaces.IMailHost five.localsitemanager now returns wrapped utilities without RequestContainers. This requires a new LookupClass. ToDo: - - real world testing - backport to the CMF 2.1 branch - write migration code for CMF 2.1 beta sites that replaces the LookupClass and removes some utility registrations - fix the GenericSetup handler - figure out if we can make acl_users an utility - in the long run, modify all tools to make them work as utilities AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Effective Date inconsistencies
Previously Wichert Akkerman wrote: > Previously Alexander Limi wrote: > > Not so: > > > > - EffectiveDate returns a *string* 'None' when it has no value (wtf?) > > That is wrong: it should return 'the time in the system default > timezone' as documented in T Products.CMFCore.interfaces.IDublinCore. I misread the interface; that only specified what should happen if no timezone is given. The interface says that the method should return a string which corresponds to the time or None if no time is set. So the behaviour you see is expected and can not be changed without breaking backwards compatibility. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests: 11 OK
Summary of messages to the cmf-tests list. Period Fri Jun 22 12:00:00 2007 UTC to Sat Jun 23 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:31:15 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005401.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:32:49 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005402.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:34:23 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005403.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:35:55 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005404.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:37:27 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005405.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:38:59 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005406.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:40:30 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005407.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:42:03 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005408.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:43:35 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005409.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:45:06 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005410.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jun 22 21:46:37 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005411.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Effective Date inconsistencies
Previously Alexander Limi wrote: > Not so: > > - EffectiveDate returns a *string* 'None' when it has no value (wtf?) That is wrong: it should return 'the time in the system default timezone' as documented in T Products.CMFCore.interfaces.IDublinCore. If Archetypes does that you should file a bugreport for it. > - Then I think "that's what 'effective' is for" — it return __FLOOR_DATE > if unset, so no False there either. ICatalogableDublinCore does not define what happens in that case, so __FLOOR_DATE is just as valid as anything else. > There seems to be no way of getting the effective date to actually return > a False value. How can a date ever be a boolean value? A data is a date. > At which point I want to ask: Can we fix this in CMF 2.1, so it is > possible to get False values from the date objects? A 'False' value for a data can never be correct. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Effective Date inconsistencies
Am 23.06.2007 um 12:07 schrieb Alexander Limi: I'd like this one to return False, not some floor value. I understand that the official CamelCase accessors always return strings (which is fine), but I don't see why "effective()" can't give a False value. Is this just historical, or is there a real reason for it? I suspect it is historical but I don't think it should return a boolean because that would have even weirder side-effects. If it returns a __FLOOR_DATE then you can easily write your own comparison to create a boolean. has an effective date and was modified afterwards Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Effective Date inconsistencies
On Sat, 23 Jun 2007 02:55:51 -0700, Charlie Clark <[EMAIL PROTECTED]> wrote: What would you rather have? An attribute error? No, I want a boolean false value. If you wish to compare the values you need to access context.effective and context_modified I already stated that this won't work, it returns __FLOOR_DATE, which makes it useless for boolean operations: def effective( self ): """ Dublin Core Date element - date resource becomes effective. """ marker = [] date = getattr( self, 'effective_date', marker ) if date is marker: date = getattr( self, 'creation_date', None ) return date is None and self.__FLOOR_DATE or date I'd like this one to return False, not some floor value. I understand that the official CamelCase accessors always return strings (which is fine), but I don't see why "effective()" can't give a False value. Is this just historical, or is there a real reason for it? -- Alexander Limi · http://limi.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Effective Date inconsistencies
Am 23.06.2007 um 11:18 schrieb Alexander Limi: Not so: - EffectiveDate returns a *string* 'None' when it has no value (wtf?) What would you rather have? An attribute error? This is the implementation from CMFDefault.DublinCore def EffectiveDate( self, zone=None ): """ Dublin Core Date element - date resource becomes effective. """ if zone is None: zone = _zone ed = getattr( self, 'effective_date', None ) return ed and ed.toZone(zone).ISO() or 'None' def ModificationDate( self, zone=None ): """ Dublin Core Date element - date resource last modified. """ if zone is None: zone = _zone return self.modified().toZone(zone).ISO() If you wish to overwrite this in your content types then fine but I think returning 'None' as a string is a correct because ModificationDate also returns a string. If you wish to compare the values you need to access context.effective and context_modified Not that I don't think some of this stuff couldn't be cleaned up: you have to convert any of these dates back into objects to internationalise them in templates! Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Effective Date inconsistencies
On 6/23/07, Alexander Limi <[EMAIL PROTECTED]> wrote: Not so: - EffectiveDate returns a *string* 'None' when it has no value (wtf?) At which point I want to ask: Can we fix this in CMF 2.1, so it is possible to get False values from the date objects? The current situation seems pretty ridiculous. I might have missed it if there is a better way, but I couldn't find any. Maybe completely out of context, but have you verified this is a CMF 2.1 issue and not Archetypes? I know Archetypes overrides many of the methods from CMF, and it might get the corner cases like this wrong. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Effective Date inconsistencies
Hi, I was trying to do a very simple template operation today: 1. Show the Effective Date if it is identical or more recent than the Modification Date 2. Show both Effective and Modification Dates if Modification Date > Effective Date Should be simple, right? Published on […] Modified on […] Not so: - EffectiveDate returns a *string* 'None' when it has no value (wtf?) - Then I think "that's what 'effective' is for" — it return __FLOOR_DATE if unset, so no False there either. There seems to be no way of getting the effective date to actually return a False value. I am forced to crazy conditions like these: tal:condition="python:context.EffectiveDate()!='None'"> and tal:condition="python:context.EffectiveDate()!='None' and context.EffectiveDate() < context.ModificationDate()"> …and then Stefan says "I don't know whole story of your condition, you may need to use == and or or whatever, point being you have to guard for EffectiveDate being 'None'" At which point I want to ask: Can we fix this in CMF 2.1, so it is possible to get False values from the date objects? The current situation seems pretty ridiculous. I might have missed it if there is a better way, but I couldn't find any. -- Alexander Limi · http://limi.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open hannosch - "[GS] Error when choosing initial_configuration ", [Accepted] http://www.zope.org/Collectors/CMF/473 tseaver - "CMF needs View-based TypeInformation", [Accepted] http://www.zope.org/Collectors/CMF/437 yuppie - "purge_old in runAllImportSteps not working", [Accepted] http://www.zope.org/Collectors/CMF/455 Pending / Deferred Issues - "workflow notify success should be after reindex", [Deferred] http://www.zope.org/Collectors/CMF/389 - "Can't add (plone) portal with plone 3.0b3 - AttributeError in DCWorkflow._executeTransition", [Pending] http://www.zope.org/Collectors/CMF/484 - "Cannot import extension profile as GS tries to write report twice", [Pending] http://www.zope.org/Collectors/CMF/486 Pending / Deferred Features - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
