Am 17.04.2011, 13:46 Uhr, schrieb William Heymann <k...@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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
