Question: additional context for IAnnotations adapter?
Hi there! While looking at the zope.app.principalannotation package, I discovered that both zope.annotation and zope.app.principalannotation register their IAnnotations adapters twice: fisrt, as a simple adapter and second, as a multi adapter for some additional context object. The zope.annotation doesn't use that additional context at all - it just allows to get annnotations by multi-adapter lookup. The zope.app.principalannotation uses the additional context object as context argument for getSiteManager, which I believe is not needed and/or used in most cases, because application components, like zope.site provide their hooks to get the right site manager. There's no documentation or any tests for that behaviour neither in zope.app.principalannotation, nor in zope.annotation, so I made an assumption that these registrations are there just to support some very old annotation pattern, that was deprecated ages ago. If it's like that, I'd like to remove that registration for zope.principalannotation that is about to born as well as for zope.annotation. Can someone clarify this point? -- WBR, Dan Korostelev
Hi Dan Dan Korostelev wrote:
Hi there!
While looking at the zope.app.principalannotation package, I discovered that both zope.annotation and zope.app.principalannotation register their IAnnotations adapters twice: fisrt, as a simple adapter and second, as a multi adapter for some additional context object.
The zope.annotation doesn't use that additional context at all - it just allows to get annnotations by multi-adapter lookup. The zope.app.principalannotation uses the additional context object as context argument for getSiteManager, which I believe is not needed and/or used in most cases, because application components, like zope.site provide their hooks to get the right site manager.
There's no documentation or any tests for that behaviour neither in zope.app.principalannotation, nor in zope.annotation, so I made an assumption that these registrations are there just to support some very old annotation pattern, that was deprecated ages ago. If it's like that, I'd like to remove that registration for zope.principalannotation that is about to born as well as for zope.annotation.
Can someone clarify this point?
I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time). In both cases it is important that the annotations are looked up in some context rather than in whatever the current site happens to be. Hope this helps Jacob
Jacob Holm wrote at 2009-3-6 01:55 +0100:
... I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time).
I expect that use cases like this (looking up objects in a foreign site context) will be important for my current employer (if it continuous to use Zope in the future). -- Dieter
2009/3/9 Dieter Maurer <dieter@handshake.de>:
Jacob Holm wrote at 2009-3-6 01:55 +0100:
... I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time).
I expect that use cases like this (looking up objects in a foreign site context) will be important for my current employer (if it continuous to use Zope in the future).
Thanks for comments. The functionality stayed and migrated to zope.principalannotation. It now even have a doctest. :-) -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/3/9 Dieter Maurer <dieter@handshake.de>:
Jacob Holm wrote at 2009-3-6 01:55 +0100:
... I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time). I expect that use cases like this (looking up objects in a foreign site context) will be important for my current employer (if it continuous to use Zope in the future).
Thanks for comments. The functionality stayed and migrated to zope.principalannotation. It now even have a doctest. :-)
It's interesting, this use case sound pretty close to what I'm talking about in the very last part of this message: http://mail.zope.org/pipermail/zope-dev/2009-March/035220.html ie: adapter context based on object traversal rather than notion of "current site". Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do:
adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB)
cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
[snip] It's interesting, this use case sound pretty close to what I'm talking about in the very last part of this message:
http://mail.zope.org/pipermail/zope-dev/2009-March/035220.html
ie: adapter context based on object traversal rather than notion of "current site".
Not quite, since this was about principal annotations and principals cannot be found by object traversal. It was specifically about letting the adapter know the context, not about finding a different adapter based on context.
Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do:
adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB)
In general, using "context=a" should give the same result as "context=siteA". In the particular case of principalannotations, this would not help. There the adapter is the same globally, but needs to know the context so it can find the proper utility to use. To make it work you'd need to register a different adapter for each utility. This is certainly doable, but probably not worth the effort. Hope this helps Jacob
Jacob Holm wrote:
Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do:
adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB)
In general, using "context=a" should give the same result as "context=siteA".
Why? What actually makes this work? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Jacob Holm wrote:
Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do:
adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB)
In general, using "context=a" should give the same result as "context=siteA".
Why? What actually makes this work?
If you provide a context in the zope.component.getAdapter call, it is used with zope.component.getSiteManager to find the "site manager" to use for the actual lookup. In this case getSiteManager does the actual lookup by adapting context to zope.component.interfaces.IComponentLookup using the global registry. In a normal setup, this will find the SiteManagerAdapter from zope.site.site (used to be in zope.app.component). This adapter simply traverses __parent__ pointers until it finds an object providing zope.location.interfaces.ISite. Depending on your setup it may actually be a different implementation of getSiteManager that is used, since it is marked with @hookable. The common replacement is zope.site.hooks.getSiteManager, which in this case does exactly the same global IComponentLookup adapter lookup I described above. If you are not using zope.site, you need to provide your own global IComponentLookup adapter to get it working. (Or hook the getSiteManager function yourself) This is a bit more complex than I remembered, but the result is that in a normal setup passing "context=A" will give the same result as "context=siteA", assuming that siteA can be found from A by following __parent__ pointers. Hope this helps - Jacob
participants (4)
-
Chris Withers -
Dan Korostelev -
Dieter Maurer -
Jacob Holm