[Dieter] >>> Now plug and play comes into play: >>> >>> Assume two packages developped by independent people >>> which all want to control the order of hook execution.
[Jim] >> Do we have evidence that such applications exist? So far, the only >> example I've seen is one where an application wanted a handler to go >> last. As I've pointed out in a separate note, this is achievable without >> the change. [Dieter] > I have a *package* (similar to Archetypes SQLStorage) that wants to go > after everything that might possibly change attributes whether those > changes are done by another component from me or any package developped > by someone else. Dieter, how does order= solve that for you? There is no value you can pass to guarantee your hook will run last. As Jim said earlier (albeit obliquely), with the old method you could guarantee that your hook ran after all hooks registered by the time a commit began, via registering a hook H1 any old time, where H1's only action when called is to register a new hook H2. The old method guaranteed to call hooks in registration order, so it was guaranteed that H2 wouldn't be called until after all the hooks that were registered at the time the commit began were called. That wouldn't guarantee H2 ran last either, but neither can order=. _______________________________________________ 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
