[Zope-dev] CatalogPathAwareness and zope.lifecycle

Charlie Clark charlie.clark at clark-consulting.eu
Sun Apr 17 11:46:51 EDT 2011


Am 17.04.2011, 17:15 Uhr, schrieb Sascha Welter <zopelist at 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


More information about the Zope-Dev mailing list