[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 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - workflow notify success should be after reindex, [Deferred] http://www.zope.org/Collectors/CMF/389 - Possible bug when using a BTreeFolder Member folder, [Pending] http://www.zope.org/Collectors/CMF/441 - Proxy Roles not Working/Applied to Worflow Transition Scripts, [Pending] http://www.zope.org/Collectors/CMF/449 - safe_html filters some tags which should probably not be filtered, [Pending] http://www.zope.org/Collectors/CMF/452 - purge_old in runAllImportSteps not working, [Pending] http://www.zope.org/Collectors/CMF/455 - PUT handling for Events is broken, [Pending] http://www.zope.org/Collectors/CMF/458 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Deferred] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - manage_doCustomize() : minor additions, [Pending] http://www.zope.org/Collectors/CMF/382 - CMF needs View-based TypeInformation, [Pending] http://www.zope.org/Collectors/CMF/437 - Marker attributes should be deprecated, [Pending] http://www.zope.org/Collectors/CMF/440 ___ 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: SVN: CMF/branches/1.6/ Use GenericSetup 1.2 branch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27 Nov 2006, at 11:53, yuppie wrote: Stefan, I don't think this is a legitimate switch: GS 1.2 is *much* later, in terms of release management, than CMF 1.6, and introduces new features. Currently GenericSetup 1.2 is the only version with a maintenance branch. CMF-1.6.1-final was tagged *after* GenericSetup 1.1, so an additional 1.1 maintenance branch would not help us. Therefore using GenericSetup 1.2 in CMF 1.6 might be the best solution. What I really don't like are externals that point to the *HEAD* of a branch. Instead of moving targets we should use revision numbers. (It might make sense to make an exception for CMF trunk.) I'm happy with any policy that we can agree on. Right now there's none, and that leads to confusion. I'd suggest a policy where a CMF maintenance branch points to the head of a GS maintenance branch, and when a CMF version is tagged its external is frozen at that particluar SVN revision for GS. There's no need to make a GS tag for a CMF release I think. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFastERAx5nvEhZLIRAk0JAJ98gvBRUQ5cdKsOSU6grqlaSMjMigCdFz+T JNqhc3IVZ1O3dI+3EM12Yy8= =qTh9 -END PGP SIGNATURE- ___ 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] Calendar
Hi, am I right in assuming that the CMF calendar tool does not provide a getNextEvent method? 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] Calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27 Nov 2006, at 13:34, Charlie Clark wrote: Hi, am I right in assuming that the CMF calendar tool does not provide a getNextEvent method? No. By the way, grep is your friend, and would have told you in a split second :) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFat+gRAx5nvEhZLIRAtgZAJ4sh9l3dp+BeoJ5dtoK5FZUkpPc9QCcDnFk FPjgfzIIq8JU6mxhJ81Tg68= =r005 -END PGP SIGNATURE- ___ 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] Calendar
Am 27.11.2006 um 13:52 schrieb Jens Vagelpohl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27 Nov 2006, at 13:34, Charlie Clark wrote: Hi, am I right in assuming that the CMF calendar tool does not provide a getNextEvent method? No. By the way, grep is your friend, and would have told you in a split second :) He isn't my friend - my brain has difficulties with the command line %-) but I asked the question after reading the source. I'm working on my own script to do the work but think it might be a good idea to have it in the tool itself. BTW. it's the first time I've come across getToolByName. How do I add additional event_types? Just patch setup_handlers? There doesn't seem to be any checking for adding valid types. 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: SVN: CMF/branches/1.6/ Use GenericSetup 1.2 branch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 27 Nov 2006, at 11:53, yuppie wrote: Stefan, I don't think this is a legitimate switch: GS 1.2 is *much* later, in terms of release management, than CMF 1.6, and introduces new features. Currently GenericSetup 1.2 is the only version with a maintenance branch. CMF-1.6.1-final was tagged *after* GenericSetup 1.1, so an additional 1.1 maintenance branch would not help us. Therefore using GenericSetup 1.2 in CMF 1.6 might be the best solution. But CMF 1.6.0 was released before 1.1, even:: $ svn propget svn:externals $ZSVN/CMF/tags/1.6.0 ... GenericSetup svn://svn.zope.org/repos/main/GenericSetup/tags/1.1-beta We shouldn't move the 1.6 release line to a newer GenericSetup release, at least without a really good reason. What I really don't like are externals that point to the *HEAD* of a branch. Instead of moving targets we should use revision numbers. (It might make sense to make an exception for CMF trunk.) I'm happy with any policy that we can agree on. Right now there's none, and that leads to confusion. I'd suggest a policy where a CMF maintenance branch points to the head of a GS maintenance branch, and when a CMF version is tagged its external is frozen at that particluar SVN revision for GS. There's no need to make a GS tag for a CMF release I think. I think we should be *trying* to keep the CMF pointed at released versions of GS, and should definitely delay making CMF releases until we can tie them to a tagged release of GS. Dependencies which are released separately need to be managed with more care. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFauee+gerLs4ltQ4RAsqrAKDZYoUIqwrHe/yDFoj+6vy6wwYIZACgtwsW XT3QZJpUQCj7JaHZWpwEjDs= =CcC2 -END PGP SIGNATURE- ___ 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: SVN: CMF/branches/1.6/ Use GenericSetup 1.2 branch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27 Nov 2006, at 14:26, Tres Seaver wrote: I'd suggest a policy where a CMF maintenance branch points to the head of a GS maintenance branch, and when a CMF version is tagged its external is frozen at that particluar SVN revision for GS. There's no need to make a GS tag for a CMF release I think. I think we should be *trying* to keep the CMF pointed at released versions of GS, and should definitely delay making CMF releases until we can tie them to a tagged release of GS. Dependencies which are released separately need to be managed with more care. That policy is great, too. We just need to make sure to cut GS releases whenever we think we need new GS features in the CMF that only exist on GS branches or the GS trunk. So far the release frequency for GS has been very slow, it might need to speed up a bit for this policy to be effective. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFaulFRAx5nvEhZLIRAp5mAKC1NmSYBBRUokXPCx82CG6qSIvQVwCfQl/J 9/uKFxZ35SCdz2O9KNgNLis= =zdDO -END PGP SIGNATURE- ___ 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: SVN: CMF/branches/1.6/ Use GenericSetup 1.2 branch.
We use CMF 1.6 branch with GS 1.2 branch in Plone 2.5. This, and itchy fingers, made me update the external. FWIW, when I check out CMF/tags/1.6.2 I expect to get a GS tag as well. When I check out CMF/branches/1.6 I expect to get the HEADs of the respective development branches. Another benefit would be that nightly tests also use branch HEADs, catching discrepancies early on. We use this policy in Plone-world to general satisfaction. Stefan On 27. Nov 2006, at 15:08, yuppie wrote: I'm fine with requiring tagged GS releases for CMF *releases*. But sometimes it is useful to link unreleased CMF branches to unreleased GenericSetup versions. This helps to avoid problems caused by stitching in new versions right before a release. -- It doesn't necessarily do it in chronological order, though. --Douglas Adams ___ 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] Calendar
Am 27.11.2006 um 14:14 schrieb Charlie Clark:
He isn't my friend - my brain has difficulties with the command
line %-) but I asked the question after reading the source. I'm
working on my own script to do the work but think it might be a
good idea to have it in the tool itself. BTW. it's the first time
I've come across getToolByName.
This is method I've come up with:
def getNextEvent(self):
Get the next event from the calendar
today = DateTime()
print today
query = self.portal_catalog(
portal_type=self.getCalendarTypes(),
review_state=self.getCalendarStates(),
start={'query': today, 'range': 'max'},
sort_on='start')
def sort_function(x,y): # this should be a utility method
for the class
# as indeed should the check for
uniqueness
z = cmp(x.start,y.start)
if not z:
return cmp(x.end,y.end)
return z
rids = []
results = []
for result in query:
if not result.getRID in rids:
rids.append(result.getRID)
results.append(result)
if results:
results.sort(sort_function)
return results[0]
return None # probably unnecessary
I've also written a simple next_event_view script and
next_event_view_template
I'd write a test for this but I've never written a test so it might
go horribly wrong! ;-)
If you wish I'd be happy to submit this although I think the changes
for unique results and sorting should also be reflected.
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
