Am 17.04.2011, 17:15 Uhr, schrieb Sascha Welter <zopelist@betabug.ch>:
Charlie, I really like this quote from the Pyramid documentation: "While the ZCA is an excellent tool with which to build a framework such as Pyramid, it is not always the best tool with which to build an application due to the opacity of the zope.component APIs." - From my point of view, wearing my "application developer hat", event handling is YAGNI. In my estimate - - 90% of Zope Products/Apps only use manage_afterAdd or use none of manage_after* - - the other 9.9% use manage_afterDelete and/or some combination for handling copy+paste. - - The other 0.1% thought very hard to find something else they thought they needed to do with events.
Actually, I am big fan of events - yes, you don't need them very often but they do solve provide a useful solution to some fairly common use cases. Of course, as you point out they are often best wrapped up in a higher level component. I'm not sure what your point with the numbers is about - you think event notifications and subscribers are overkill given that pretty much only manage_afterAdd and manager_afterDelete are used? Maybe, but I think that's semantics. The important thing for me is that there is no magic. As to the larger point of how suitable is the component architecture for application development I think the main point that Chris is making, and I hope he'll correct me if this is not the case, is that doing everything with the ZCA, especially with registration is counter-productive: pluggability is not really a design goal for an application.
So a full feature, "we have it all for you" framework like Zope has been doing fine to offer these few in an easy and simple way. Pyramid gives me full event handling as an optional extra, because Pyramid is a "you pay only for what you eat" framework and I might not even need those few that Zope offers out of the box - or I might be in the 0.1% and need the full deal.
I beg to differ: Zope's SimpleItem is anything but and it's bastard Plonish offspring Archetype causes even more by offering convenience at the cost of complexity. Zope as a full-featured framework is a misconception: it is an application.
Interfaces is even more YAGNI in the role of the application developer. (Which is what the pyramid doc is saying there IMHO.)
Interfaces suffer most from conceptional vagueness. As an attempt to document the intent of classes they suck - that is pretty much what docstrings are for. I have found them to be most useful as: a) marker's and b) form schema templates. Of course, b) is something probably something they really shouldn't be used. Now I tend to see them as markers first with the possibility of being expanded to full-blown interfaces if pluggability becomes desirable.
I don't write a framework where you can swap out one templating system for another, I just write an app that is finished at one point in time.
I think everyone agrees on this nowadays. I do, however, like the ability to swap out the backend for deployment purposes if required.
As for Philip's book, I guess you are aware that lots of it is already outdated. Something to keep in mind and tell people when one recommends that book. (Philip is well aware of that and his "in hindsight, the book should have been free/open" blog post is quite interesting.)
Some of the detail is pretty much out of date but I still think it is a great handbook on the component-based approach to application development. Speaking as someone who has no CS background and is only a part-time programmer I found it incredibly helpful in structuring my approach to problem solving and really benefited from the extensive explanation of some of the more esoteric stuff that has now become more or less standard.
@Sascha I'm not sure if this will answer your question but you might want to look at how Products.CMFCore.CatalogAware works.
Thank you. This would answer my question if someone told me to take over maintenance of CatalogAware / CatalogPathAware in Products.ZCatalog and I'd have to rewrite it instead of just writing tests and if I then asked the question "where do I start?".
I think I detect some irony there. Sorry that it doesn't help you. 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