Re: Registering event-handler in CompenentRegistry - a good idea? (refs plone.multilingual)
David Glick <david.glick-z4DKO/[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.devel |
|---|---|
| Message-ID | <[email protected]> |
Maybe it would be best to add modified items to a queue that gets processed when the transaction is committed (like how collective.indexing does for indexing objects). Both this and your solution have the potential problem that a change to an object will not immediately be reflected on its translations. Not sure if that is likely to be a problem in practice. David Glick (mobile) > On Feb 16, 2014, at 7:07 AM, Wolfgang Thomas <[email protected]> wrote: > > Hi, > > while debugging a massive performance lag in plone.multilingualbehavior, I stumbled across a general problem. It leads me to doubt that registering an event handler in the component registry (as opposed to registering in zcml) is a good idea (using Plone 4.3.2). > > Explanation: > I will use plone.multilingualbehavior as an example, where an event handler is registered via Generic Setup [1]. > One of the principles of GS is idempotence, i.e. you can run an import step multiple times, and the result is always the same. To be concrete, the event handler should be present in the component registry exactly once, no matter how often the GS profile is applied. And indeed, GS _seems_ to guarantee this: The handler is first unregistered, then registered again. [2] > > But the unregistering fails in Plone 4.3.2. To understand this, we need to look at zope.component in the version used by Plone 4.3.2, which is 3.9.5. The unregisterHandler() method is the key: [3] > > In short, it takes a list of interfaces (param "required") and a factory. It searches through its own handler registration and throws out all existing registrations that match both the factory and the list of required interfaces. > > The problem lies in comparing the factory. Every time GS calls unregisterHandler(), it has built a _new_ instance of the factory, which will never match any factory in the list of existing registrations. > > As a result, every run of GS (for the componentregistry step) will add a new handler registration, not replace an existing one. > > If the __class__ were use for comparing, instead of the factory itself, unregistering would work. Proof of concept: [4] > > > My questions: > > * Known issue, or should I file a bug report for GS? > > * Generally speaking: What is the use of registering event handlers (and also adapters) in the component registry? Is there any benefit over registration via zcml (i.e. on startup)? In my experience, persisting configuration in the ZODB puts a high demand for clean un-install on the package that does it. Especially since the component registry is a piece of black magic, and even more so the zope.interface.adapter.AdapterRegistry. - Easy to overlook something. > > I've had too many cases of a broken site after removal of some package code due to persistent utilities or other persistent components in the past years to be a fan of this approach. > > Opinions? > > Cheers, > Wolfgang / pysailor > > > > [1] https://github.com/plone/plone.multilingualbehavior/blob/master/plone/multilingualbehavior/profiles/default/componentregistry.xml#L4 > [2] https://github.com/zopefoundation/Products.GenericSetup/blob/master/Products/GenericSetup/components.py#L259 > [3] https://github.com/zopefoundation/zope.component/blob/3.9.5/src/zope/component/registry.py#L344 > [4] https://github.com/plone/plone.multilingualbehavior/blob/use_editfinishedevent/plone/multilingualbehavior/upgrades/upgrades.py#L39 > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Plone-developers mailing list > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/plone-developers ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Plone-developers mailing list Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/plone-developers