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.
Great!
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.
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
