Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Jeff Shell wrote: On 12/15/05, Martijn Faassen [EMAIL PROTECTED] wrote: [snip] One troublesome scenario I can imagine is that if I make my total skin in Zope 3.n, it works, and then Zope 3.n + 1 is released and it has a more specific view registered for some content object that I'm using. I was relying on having skinned the more general interface, but suddenly in Zope 3.n + 1 I get the Zope 3 view. That'd be bad. So, I'm not sure whether or not this ability is compromised in practice with this bugfix... If it is compromised, it may be bad design on your part? That's the decision that I came to. If it's truly the case that this is due to bad design, then that's good to hear. You obviously have more experience with this problem than I do, I'm just leaping into this thread with vague concerns. [snip details] I'm still unsure about how I feel about this situation in my gut. The Zope 3.1 way felt strangely intuitive, but I recognize why it was incorrect and why the 3.2 implementation does what it does. [snip] For us at Bottlerocket, these core objects have bitten us in the past. So for me - and I'm not saying it applies for you or anyone else - this change to the 'correct' behavior for multi-adapter lookup has highlighted some design flaws in our code and way of thinking. If this issue didn't show itself now, a different issue may have shown up in the future. Okay, we'll see whether this turns up any flaws in the DocumentLibrary in this department; we haven't tried it with Zope 3.2 yet. It's good to hear your conclusion that this is essentially the right behavior, though the counterintuitiveness Thanks for the debug module, I'll tuck it away somewhere! Might be useful to put this somewhere under svn.zope.org or something, by the way. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Heads up, adapter-registry refactoring (was Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?)
I'm hoping to redo the internal details of a adapter registries in the next release cycle, along the lines of work done in the jim-adapter-redesign branch. This redesign has the following goals: - Bring the adapter-lookup algorithm closer to the somewhat familiar method-lookup algorithm for Python new-style classes. Of course, this is extended (in an ovious way) to deal with multiple dispatch. This new algorithm should give the same results as the current mechanism. In fact, I delayed working on the multi-adapter fix, hoping that I would achiev the same result with the new lookup mechansim. - Provide an equivalent to super for adapter lookup. If an adapter overrides another adapter, it should be possible for the overriding adapter to find and use the adapter it overrides. - Provide greater performance. I had originally hoped to achive the last goal without use of any caching. (The current algorithim is based on very extensive caching.) Alas, without caching the new algorthm is too slow, and much slower than the existing alsgorthm. I am hopeful that with a much simpler and less expensive cache in front of the new algorthm, I'll be able to meet current performance for single-adapter lookup and greatly improve performance for multi-adapter lookup. I expect to be able to report results in January. Obviously, this refactoring will render obsolete tools writted against the current implementation. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Jim Fulton wrote: Jeff Shell wrote: I understand why this is happening, but it's (obviously) not what I want to have happen. I want MY skin layer's declaration of 'contents.html' to win out. It actually works for all container types, so maybe I need to declare it for a root Zope container interface for my layer? I don't know enough about the relationshipd between your content interfaces, to comment directly, but I will note that the intent was that content interface would have precedence over skin. This was not the case before due to a bug in multi-adapter lookup. While I probably don't understand some details, this thread rather worries me. Imagine I'm writing my own custom skin 'IFoo', that has a page directive for the page 'index' for Zope's 'IContainer' (say), in a layer that's in the skin 'IFoo'. Now someone whose skin setting is set to IFoo is looking at IFolder, which is an IContainer. Zope registers a 'index' page specific for IFolder. Would now Zope's more specific registration win? How would I accomplish making a skin that takes care about overriding *all* IContainers without having to explicitly register for all sub-interfaces? Or am I wrong in even imagining this would be desirable? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Martijn Faassen wrote: Jim Fulton wrote: Jeff Shell wrote: I understand why this is happening, but it's (obviously) not what I want to have happen. I want MY skin layer's declaration of 'contents.html' to win out. It actually works for all container types, so maybe I need to declare it for a root Zope container interface for my layer? I don't know enough about the relationshipd between your content interfaces, to comment directly, but I will note that the intent was that content interface would have precedence over skin. This was not the case before due to a bug in multi-adapter lookup. While I probably don't understand some details, this thread rather worries me. Imagine I'm writing my own custom skin 'IFoo', that has a page directive for the page 'index' for Zope's 'IContainer' (say), in a layer that's in the skin 'IFoo'. Now someone whose skin setting is set to IFoo is looking at IFolder, which is an IContainer. Zope registers a 'index' page specific for IFolder. Would now Zope's more specific registration win? Yes. How would I accomplish making a skin that takes care about overriding *all* IContainers without having to explicitly register for all sub-interfaces? You can't currently. Or am I wrong in even imagining this would be desirable? I think so. If there are custom views for more specific interfaces, it is likely those custom views provide features that your generic view doesn't. It would be a bit unkind for your view to override those. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: View lookup changes in Zope 3.2?
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion. This is a major blocking / freaking out kind of
issue. I'm trying to figure out now how to crawl through the debugger
and test the 'getMultiAdapter' lookup for this skin + object to
compare the results and hopefully.. I don't know. I have a pretty
complex view declaration that's meant to replace 'contents.html' for a
lot of our containers, and I'm hoping that I don't have to re-declare
the view for each container type. I guess I should also learn more
about how everything collaborates to establish an objects interfaces
and in what order so I can ensure that the base Zope interfaces are
lower on the providedBy list?
On 12/12/05, Jeff Shell [EMAIL PROTECTED] wrote:
Today I finally got around to installing Zope 3.2b1 and started
testing one of our sites against it. I'm running into a few problems,
some of which are my fault, some that I don't quite understand, and
one that is really bad.
We have been basically rolling a custom CMS in Zope 3, and the content
management skin that we made has been working wonderfully in Zope 3.1.
One of the key parts of our CMS's user interface is a custom contents
view that uses MochiKit for javascript/DOM based table sorting (easy
sorting on item name, title, and size), and uses MochiKit's AJAX
support for inline renaming/retitling of items in the container.
That's registered as 'contents.html' for our own base contentcontainer
interface. We've also made a custom metadata view that allows editing
of keywords (subjects).
In Zope 3.1.0 both of those worked fine.
In Zope 3.2b1, I'm getting the Rotterdam or default contents view,
wrapped up in our template. The same goes for the custom '@@+' view
I've made for the same objects, which is used to filter certain Zope
entries out of the add menu. For our container objects, I'm also
getting the Zope meta-data view, but on some of our custom content
objects I get our replacement view.
I use our own menu, 'cms_views', for tabs, and have contents and
EditMetaData registered as actions.
If I rename my 'contents.html' view to 'contentsplus.html', I can see it fine.
Here's my skin setup:
from zope.publisher.interfaces.browser import IBrowserRequest
from zope.publisher.interfaces.browser import IDefaultBrowserLayer
from zope.app.rotterdam import rotterdam
class CMS(IBrowserRequest):
The `cms` layer.
class ContentManagement(CMS, rotterdam, IDefaultBrowserLayer):
The Skin
configure:
layer name=example.cms
interface=example.cms.skin.CMS/
skin name=example.cms.ContentManagement
interface=example.cms.skin.ContentManagement/
and the contents.html view starts with:
view name=contents.html for=example.cms.interfaces.IContentContainer
permission=example.cms.ManageContent
layer=example.cms.skin.CMS
I'm referring to the layer with its interface path in ZCML, always.
If I moved 'rotterdam' out of the base interfaces for the
ContentManagement skin and set it as the base for the CMS layer
object, the same behavior still shows up.
This setup works as I expected it to in Zope 3.1, but breaks in Zope 3.2.
FWIW, I opened up a debugzope session in both Zope 3.1 and 3.2 in this
same configuration just to check the list of providedBy(obj) for the
same folder in each site, to see if the interface resolution order
might have changed, but the lists appear to be identical.
Bug? Or did I do something wrong in my Zope 3.1 implementation that
Zope 3.2b1 has fixed?
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Just get a check out and merge out that change:
svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
and see if you still have the problem. If you don't, then you still have some
digging to do. If you do, then well, lets get into that if you
verify that that is the problem.
This was an honest-to-gosh bug. It is also the case that there were
registrations in Zope that depended on this bug and had to be changed.
We should have fixed this in 3.1. I'm sorry we didn't.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Just get a check out and merge out that change:
svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
and see if you still have the problem. If you don't, then you still have some
digging to do. If you do, then well, lets get into that if you
verify that that is the problem.
This was an honest-to-gosh bug. It is also the case that there were
registrations in Zope that depended on this bug and had to be changed.
Going through a lot of debugging, it looks as through it has to do
with how things are ranked in
zope.interface.adapter.AdapterLookup.lookup() for multi-adapters. I
haven't stepped through it in the debugger in Zope 3.1 yet, but I just
got finished doing it in Zope 3.2 and these are my results:
from zope.app.component.hooks import setSite
from zope.publisher.browser import TestRequest
from zope.app import zapi
from zope.publisher.interfaces.browser import ISkin, IDefaultSkin
conman = zapi.getUtility(ISkin, name='br.cms.skin.ContentManagement')
customer = debugger.root()['customer']
setSite(customer)
winter = customer['winter']
contents = zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')
contents.__class__.__bases__
(class 'zope.app.container.browser.contents.Contents', class
'zope.app.publisher.browser.viewmeta.simple')
So then I do a pdb.run(zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')) and it's inside
AdapterLookup that I get the following. When all of the adapters for
this container and the request with the name 'contents.html' are
looked up:
(Pdb) pp byname.get(name)
[((InterfaceClass zope.app.folder.interfaces.IFolder,
InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer),
class 'zope.app.publisher.browser.viewmeta.Contents'),
((InterfaceClass br.cms.interfaces.IContentContainer,
InterfaceClass br.cms.skin.CMS),
class 'zope.app.publisher.browser.viewmeta.contents.html'),
((InterfaceClass br.cms.interfaces.IContentFolder,
InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer),
class 'zope.app.publisher.browser.viewmeta.Contents')]
The one the I want is the second set in this list, 'br.cms.skin.CMS'.
Unfortunately, that's the one that loses out in the ranking algorithm
that ranks based on interface's ranking in the spec resolution order.
(NOTE: The IContentContainer there is different than the Zope
IContentContainer! This has cause some confusion in house)
The first one (IFolder, IDefaultBrowserLayer) produces the rank: (4, 4)
The second one, which I want, (IContentContainer, CMS) produces the rank (12, 2)
The third one, which I'm suspecting is generated from a zcml
containerViews directive, wins with the rank (3, 4).
It wins because the 'best' tuple is kept around. A rank wins 'best' by
being less than the current 'best', and (3, 4) is less than all of
them.
I understand why this is happening, but it's (obviously) not what I
want to have happen. I want MY skin layer's declaration of
'contents.html' to win out. It actually works for all container types,
so maybe I need to declare it for a root Zope container interface for
my layer?
I've been living under the impression that the layer a view was
assigned to had higher precedence than may have been intended, and
maybe this is part of the discussion going on in the
'SimplifySkinning' proposal/thread which I should take a closer look
at.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Jeff Shell wrote:
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Just get a check out and merge out that change:
svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
and see if you still have the problem. If you don't, then you still have some
digging to do. If you do, then well, lets get into that if you
verify that that is the problem.
This was an honest-to-gosh bug. It is also the case that there were
registrations in Zope that depended on this bug and had to be changed.
Going through a lot of debugging,
Did you do the experiment I suggested? (above)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Jeff Shell wrote:
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Just get a check out and merge out that change:
svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
Going through a lot of debugging,
Did you do the experiment I suggested? (above)
Yes. Against that merge, against a Zope 3.2b1 release, applying those
specific revisions to the 3.2b1 release, even going back to the
revisions listed in Collector Issue 396, the same result happens.
I assume that, by the same result happens, you mean that your application
works the way it did before. No, that can't be.
I screwed up and gave you the wrong revision number. The revision in which I
fixed this bug was 39948, so the merge should have been:
svn merge -r39948:39947 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
It's one that makes sense to me, in its way. As stated in the
debugging output message, I just expected the layer to somehow have a
higher precedence than it does. At the multi-adapter lookup level, I
think I can understand why the new code does what it does. I may just
need to re-evaluate how my interfaces are declared, or what my
subclassing is causing to happen, or how my views are declared.
Here's a bit more detail.
When we look up multi-adapters, we want to look up adapters that
fit the first object best, and, if more than one adapter require the same
first interface as the one that fits the first object best, then, among
those we prefer the ones that fit best for the second object, and so on.
There was a bug that caused the adapter that fit the second object
best to be prefered, as long as it also matched the first object at all.
This is illustrated by the test shown in
http://www.zope.org/Collectors/Zope3-dev/396
This bug has now been fixed.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Jeff Shell wrote: ... Going through a lot of debugging, it looks as through it has to do with how things are ranked in zope.interface.adapter.AdapterLookup.lookup() for multi-adapters. Yup. I haven't stepped through it in the debugger in Zope 3.1 yet, but I just got finished doing it in Zope 3.2 and these are my results: from zope.app.component.hooks import setSite from zope.publisher.browser import TestRequest from zope.app import zapi from zope.publisher.interfaces.browser import ISkin, IDefaultSkin conman = zapi.getUtility(ISkin, name='br.cms.skin.ContentManagement') customer = debugger.root()['customer'] setSite(customer) winter = customer['winter'] contents = zapi.queryMultiAdapter((winter, TestRequest(skin=conman)), name='contents.html') contents.__class__.__bases__ (class 'zope.app.container.browser.contents.Contents', class 'zope.app.publisher.browser.viewmeta.simple') So then I do a pdb.run(zapi.queryMultiAdapter((winter, TestRequest(skin=conman)), name='contents.html')) and it's inside AdapterLookup that I get the following. When all of the adapters for this container and the request with the name 'contents.html' are looked up: (Pdb) pp byname.get(name) [((InterfaceClass zope.app.folder.interfaces.IFolder, InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer), class 'zope.app.publisher.browser.viewmeta.Contents'), ((InterfaceClass br.cms.interfaces.IContentContainer, InterfaceClass br.cms.skin.CMS), class 'zope.app.publisher.browser.viewmeta.contents.html'), ((InterfaceClass br.cms.interfaces.IContentFolder, InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer), class 'zope.app.publisher.browser.viewmeta.Contents')] The one the I want is the second set in this list, 'br.cms.skin.CMS'. Unfortunately, that's the one that loses out in the ranking algorithm that ranks based on interface's ranking in the spec resolution order. (NOTE: The IContentContainer there is different than the Zope IContentContainer! This has cause some confusion in house) The first one (IFolder, IDefaultBrowserLayer) produces the rank: (4, 4) The second one, which I want, (IContentContainer, CMS) produces the rank (12, 2) The third one, which I'm suspecting is generated from a zcml containerViews directive, wins with the rank (3, 4). It wins because the 'best' tuple is kept around. A rank wins 'best' by being less than the current 'best', and (3, 4) is less than all of them. I understand why this is happening, but it's (obviously) not what I want to have happen. I want MY skin layer's declaration of 'contents.html' to win out. It actually works for all container types, so maybe I need to declare it for a root Zope container interface for my layer? I don't know enough about the relationshipd between your content interfaces, to comment directly, but I will note that the intent was that content interface would have precedence over skin. This was not the case before due to a bug in multi-adapter lookup. I've been living under the impression that the layer a view was assigned to had higher precedence than may have been intended, Yup. and maybe this is part of the discussion going on in the 'SimplifySkinning' proposal/thread I hope not. which I should take a closer look at. Me too. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
