Jim Fulton wrote at 2005-8-31 18:02 -0400: > ... >> The "order gimmick", while not universal, provides an easy >> and understandable facility to handle a large group of such >> use cases. > >Huh? It doesn't help these use cases at all.
Of course, it does: together with values assigned by the integrator... > ... >> Contrary to your opinion, hooks will probably rarely have the >> need to be called as the very first or the very last one. >> Usually, the requirements will be: after I was executed >> some (hook) specific things should not happen anymore (because, >> otherwise, I would need to run again). > >You might be right, but the only credible use case I've seen >is to go last. No "social" hook may require to come last (or first). We want to enter an open world where independently developed components can be easily integrated -- ideally by configuration only. No such component may pose an exclusive claim such as "my callback must be called the very first" or "the very last". Instead, they must describe what operations should be completed before they run -- and leave it to the integrator to coordinate the various uses of the resource (in our case the callback). The framework should provide easy and understandable means for this coordination work by the integrator. >The example Julien has something going first >and something going last. I am sure Julien did not claim that his callbacks must be called the first or the last. Instead, he provided a partial order for his callbacks -- without restricting third party callbacks. Depending on what the callbacks do, they may need to go before, after or between the CPS callbacks. For example: if the "IndexationManager" would change attributes (such a e.g. a state "indexed"), then my SQL-store callback should go after the "IndexationManager"; otherwise it would not matter (in fact, I do not expect the IndexationManager to change attributes). > ... >The example you gave above had subscribers that wanted to go last. No, I would not even conceive such components -- because I want them "social"... They do *NOT* want to go last. They want to go sufficiently late such that after they executed, the state they manage should not change again. This is much weaker than the requirement to go last: only a single callback can go last, but a whole family of them (hopefully all required in a given system) can go sufficiently late. >What evidence to I have of other orderings? Julien did give >a "future need" to order two specific systems. IMO, having >one system implement that requirement explicitly by invoking >the other would be much clearer than having the >requirement implemented implicitly through integers orders. You are having a completely different perspective. Ours is as follows: There is a wealth of Zope related "tool boxes": ZODB, Zope, CMF, Archetypes, Collectives, CPS, Silva, Plone, a large set of third party products, our own toolbox. We compose applications from tools of those boxes. If necessary, we fix/extend/adapt foreign tools and enhance our toolbox. If possible, we want to touch foreign tools only superficially, ideally through configuration only. If such tools start to use the callback mechanism (I am sure, some of them will), this use is likely to be deeply hidden. I do not expect that it will be easy (in the sense of touch superficially only) to virtualize access by indirecting through a coordination component of our own. One the other hand, adjusting some "order" parameters only seems much easier. Thus, while you see the situation that one "system" knows another well and uses its services, I see the situation of several individually and independently developped "components" that I need to integrate -- and I am happy when the basic coordination means are provided by components below all of them: Zope, ZODB, CMF. > ... >Then propose a common framework. I have no problem with a common >framework. Put it in Zope if you want. It doesn't belong >in ZODB. Fine. -- Dieter _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
