[Zope-CMF] Re: tools-as-utilities, merging, releasing, etc
Sidnei da Silva wrote: That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. Yes, the ZPublisher should be firing it. But it doesn't. While it's clearly an oversight for Zope 2.10, I wonder if it can be classified as a bug or not. Probably not. Certainly a lot of existing Zope 2 ISites will have this hideous persistent before-traverse hook that came to us via whoever thought of Five.site (*cough* right, Sidnei? :)). So if the ZPublisher introduces this event, we'll ahve to be careful that it won't be sent twice for an object... Patches are welcome :). -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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: tools-as-utilities, merging, releasing, etc
Sidnei da Silva wrote: That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. That might be right, I'm not familiar with the details. But Zope 2.10 doesn't fire the BeforeTraverseEvent, so CMF has to do it somehow. I just refactored a dynamically set 'before traverse hook' using a hardcoded call in __before_publishing_traverse__. AFAICS that didn't make things worse. 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] Re: tools-as-utilities, merging, releasing, etc
That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. -- 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] Re: tools-as-utilities, merging, releasing, etc
Hi Jens! Jens Vagelpohl wrote: On 28 Feb 2007, at 15:14, Rocky wrote: Now that I have completed the primary functionality for five.localsitemanager it seems to me that the CMF jens_tools_as_utilities branch should be ready for merging into trunk in anticipation of the of the next cmf 2.1 alpha/beta release. It's ready for merging when we have a story for existing sites, meaning a clear migration path. I was going to do some simple testing closer to this weekend (busy until then) and do a simple script that can be run via zopectl run and document it if no one else has a better idea or steps up. My assumption here is that the script needs to do two things for each CMF Site encountered in the ZODB: - - create the new magic component registry - - duplicate tool registration as done by the GS componentregistry step Please correct me if I am wrong. I resolved the first part some days ago: http://svn.zope.org/?view=rev&rev=72782 But I'm not sure if "notify(BeforeTraverseEvent(self, REQUEST))" is in the right place. Maye it should just be called by PortalObjectBase, not by all DynamicType subclasses. BTW: While fixing the tests a month ago I made two quick and dirty changes, adding some XXX comments: - in SkinnableObjectManager http://svn.zope.org/?view=rev&rev=72251 - in PropertiesTool http://svn.zope.org/?view=rev&rev=72252 Maybe someone can work on a more sophisticated solution and tests? 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
[Zope-CMF] GenericSetup: catalog.xml ideas
Hi,
I have been busy with catalog.xml in the GenericSetup profile of a
Plone product (eXtremeManagement). I encountered a few uses cases
there that are not met by the current implementation of
GenericSetup/ZCatalog/exportimport.py
I am using the GenericSetup from the plone 2.5 bundle, which includes:
svn://svn.zope.org/repos/main/GenericSetup/branches/1.2/ZCatalog
But I see that trunk does not have changes that are relevant to this
case.
So here are some points, with suggested changes to the _initIndexes
function in exportimport.py. The tests even run after this, so it
seems these changes do not break anything. But I have not *added*
tests for this.
1. Removing an index
Currently, you can add an attribute 'remove' to an index in
catalog.xml. This means the index will be removed. Presumably this
is meant to remove an index that was previously used by a product but
is now not necessary anymore or even harmful.
When you apply this profile a second time, you run into an error.
Here as a test I added remove="True" to the getAssignees index:
...
Module Products.GenericSetup.ZCatalog.exportimport, line 101, in
_initIndexes
Module Products.ZCatalog.ZCatalog, line 1018, in delIndex
Module Products.ZCatalog.Catalog, line 262, in delIndex
CatalogError: The index getAssignees does not exist
And of course it is absolutely fine that this index does not exist, as
I want it removed anyway. :)
This can be fixed with the following change to exportimport.py (around
line 94):
if child.hasAttribute('remove'):
-zcatalog.delIndex(idx_id)
+# Remove index if it is there; then continue to the
+# next index.
+if idx_id in zcatalog.indexes():
+zcatalog.delIndex(idx_id)
continue
2. Changing an index
I had a FieldIndex getAssignees, which is in any Data.fs that uses the
eXtremeManagement product. I found out that it was better to make
this a KeywordIndex. So I added this to my catalog.xml:
The only effect this has is that the index is cleared: all values are
gone (which will be my third point below). The index itself is still
a FieldIndex, not the KeywordIndex that I requested.
So I propose a new attribute that can be used in catalog.xml:
'purge'. When this attribute is set, the index gets removed and then
readded, which will mean that in my case the index would become a
KeywordIndex like I wanted.
This can be done with the following change (around line 100):
+if child.hasAttribute('purge'):
+# If the index is there, remove it; this can be used
+# to remove an index with the same name but a wrong
+# meta_type.
+if idx_id in zcatalog.indexes():
+zcatalog.delIndex(idx_id)
+
if idx_id not in zcatalog.indexes():
This is not ideal, as it always destroys the index, even when it is
already correctly there, but it is an improvement.
3. Keeping an index
---
When you mention an index in your catalog.xml, GenericSetup clears it:
after applying the profile, the index has zero values. For me it
seems more logical to keep the index if it is already there. In the
current situation, I have learned to work around this by adding a
dependency step with some code that reindexes those cleared indexes.
This can take a long time so I would like to avoid doing that on each
reinstall, especially when I am busy developing this product and am
often reinstalling it or reapplying the profile.
So I propose a new attribute that can be used in catalog.xml:
'keep'. When this attribute is set and the index is already there,
just do nothing and get on with the next index. If the index is not
there, add it.
This can be done with the following change (around line 108):
meta_type = str(child.getAttribute('meta_type'))
zcatalog.addIndex(idx_id, meta_type, extra)
+elif child.hasAttribute('keep'):
+continue
Or maybe some attribute can be added like 'reindex' or
'reindex_when_new', which would trigger a reindex of the index,
possibly only when the index was added this time and not when it was
already there. This might be an attribute of the catalog tool object
itself. This would at least avoid the need of having to add
non-GenericSetup code to force a reindex.
4. Keep when no change; purge otherwise
---
As a probably better alternative, it would be nice to do all this
automatically without any extra attributes.
- When the settings for the index are the same in catalog.xml and in
the current catalog: do nothing.
- When at least one setting is different, remove the index and add it
with the new settings.
This seems more difficult to implement though.
Does this make sense?
Or has this been debated to death already with
[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Wed Feb 28 12:00:00 2007 UTC to Thu Mar 1 12:00:00 2007 UTC. There were 9 messages: 9 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: Wed Feb 28 21:37:30 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004208.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:39:00 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004209.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:40:30 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004210.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:42:00 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004211.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:43:30 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004212.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:45:00 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004213.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:46:30 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004214.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:48:00 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004215.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Feb 28 21:49:30 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004216.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
[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 - "Danger from Caching Policy Manager", [Pending] http://www.zope.org/Collectors/CMF/460 - "properties setup handler: support for non-ascii strings", [Pending] http://www.zope.org/Collectors/CMF/468 - "CMFUid reindexes all fields unnecessarily", [Pending] http://www.zope.org/Collectors/CMF/469 - "GenericSetup snapshot redirect does not work", [Pending] http://www.zope.org/Collectors/CMF/470 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 - "New getNextEvent Method", [Pending] http://www.zope.org/Collectors/CMF/462 ___ 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
