Am 17.04.2011, 13:46 Uhr, schrieb William Heymann <>:

> I have spent some time looking at other frameworks and most just don't  
> look very promising to me. For grok my biggiest issue was fail open. It  
> looks like the default is allow everything unless explicitely denied and  
> I feel that is just a recipe for disaster. Pyramid looks pretty good and  
> it does have a
> security system that you can set to fail closed but still I have a  
> massive investment in zope 2.x and I don't want to just throw that away  
> for nothing. We still manage to massively outdo our competitors using  
> much newer technology in time to get a solution done, in cost and in  
> reliability.

> So I would just like to see zope 2.x remain a viable platform and if  
> things
> are to be removed or deprecated the replacement systems need some level  
> of docs. Idealy, if I could, I would make it so that varous  
> manage_before* and manage_after* type events would just call the  
> zope.lifecycle stuff as a
> compatibility layer so all the old code would go away but old apps would  
> work and the code itself would serve as instructions on how to upgrade.

> That way CatalogPathAwareness would stay but basically just be a wrapper  
> for zope.lifecycle if that is possible.


it would be great to see the things happen that you wish but the fact is  
Zope 2 has lost most of its developers already. If you want something in  
there you have to be prepared to do it yourself. I'm still a huge fan of  
everything that Zope achieved and agree with you totally that it is still  
more capable in many respects than many competitors but the world has  
moved on and it is important to move with it. Zope 2 is largely in  
maintenance mode with things being removed from the core because there is  
no one prepared to maintain them and they are not considered essential by  
those who are maintaining Zope 2 and making sure it can run on modern  
systems, etc. I, for one, are very grateful that this work is being done.

As for an explanation of how to use events or simply getting a grasp of  
using the ZCA in Zope 2 I can highly recommend Philip von Weiterhausen's  
book on Zope 3. In many ways this is the missing Zope manual. Fortunately,  
many Zope inspired projects have learned from our consistent failure to  
provide good documentation and insist on it being part of the project.

A brief and personal summary of the difference between events versus  
"magic" manage_* methods: events are explicit, ie. you must register a  
subscriber to a particular event or explicitly notify that an event has  
happened. This is perhaps a bit verbose but it gives you more control and  
helps you break functionality out of bloated classes. The signatures for  
event subscribers does take a while to learn but is reasonable. I suppose  
that it would be possible to scan source code automatically for manage_*  
methods and try and register subscribers on the fly but this would be  
against the spirit of the ZCA. In reality decorator-based registration as  
practised in Pyramid and Grok is a good compromise.

@Sascha I'm not sure if this will answer your question but you might want  
to look at how Products.CMFCore.CatalogAware works.

Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to