Rupert Redington wrote:
That's the right aproach to implement ILocation straight to adapters or
you could use the locate attriubute of the adapter directive (-> see
zcml-referenc zope.adapter). Then the adapter uses the location proxy
I prefer the trusted adapter because they encapslulate the adapter
inside a security proxy. Then the trusted
adapter has full access to the underlying object. That simplifies the
security story very much because you handle it on the adation level. If
you use locatable and trusted adapters everything works like you would
access a regular content object.
That makes sense - though I'm not clear about how to make an adapter
"locatable" - which I think is the root cause of my next problem :(
When I apply the techniques which worked (with your help) in my
adaptertest case to the marginally more complex case I'm working on I'm
denied access to the editForm - the error page which appears when I
decline to authenticate contains nothing but "You're not allowed in
here" and the name of the first schema field specified in my
I made an attempt to remedy this by having my adapter implement
ILocation - but all that gains me is a failure to find __parent__ -
which is fair enough - since I can't see where I'd have got one from...
I'm at a loss to know why one example works and the other doesn't.
My assumption is, that your interface ILinkDetail extend ILocation
somehow. In that case both attributes __parent__ and __name__ get
protected by your class-declaration for LinkDetail. If so, don't derive
from ILocation and it should work.
We are using the adapter mechanism everywhere. Your usecase should work
Zope3-users mailing list