Hi Jens!

Jens Vagelpohl wrote:

On 14 Nov 2006, at 11:41, yuppie wrote:

AFAICS GSLocalAddons doesn't depend on CMF and might be useful for other projects as well. Don't know if you did that already, but please add the code to GenericSetup, not CMFCore.

I think this is a good time to create a maintenance branch for GenericSetup 1.2 and to make the GenericSetup trunk depend on Zope 2.10.

Good point, right now the code is purely in the CMF, but it can be moved. I'll create the 1.2 branch right now and then move the GSLocalAddons bits into GenericSetup trunk, and change DEPENDENCIES.txt.


Since CMF site roots have anyway their own class, I think we should hardcode the Zope 3 site stuff. I only had a quick look at the code so I might be missing something, but implementing this in PortalObjectBase seems to be quite easy. And we would neither need to use importVarious nor to write migration code.

Looking at the calls that are being done to make it into a Zope 3 site it seems a complicated affair to hardcode that stuff in at class level so that it will be picked up for older installations. Do you have any specific ideas about that? Otherwise it is easy to at least move the code from importVarious into a handler for ISiteRoot/IObjectAddedEvent.

As I said already: I might be missing something. But this is what I would try:

All enableSite() really seems to do is adding ISite as interface and adding a BeforeTraverseEvent notification hook. If we hardcode it in the class, we don't need the (un)registerBeforeTraverse dance. We can simply add a __before_publishing_traverse__ to PortalObjectBase. (And make sure the inherited code from DynamicType is called as well.)

Replacing the setSiteManager() call might be harder. If you want, I can have a closer look at this after you checked in your changes.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to