Rupert Redington wrote:

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.
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 mechansim.

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 in principle.


Zope3-users mailing list

Reply via email to