[Zope-dev] CatalogPathAwareness and zope.lifecycle
Charlie Clark
charlie.clark at clark-consulting.eu
Sun Apr 17 08:58:12 EDT 2011
Am 17.04.2011, 13:46 Uhr, schrieb William Heymann <kosh at aesaeion.com>:
> 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.
Hi,
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
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
More information about the Zope-Dev
mailing list