[Zope-CMF] Re: Tools as local utilities

[yuppie]

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