addendum...
I tried to implement your solution [Revision 30053], but then I noticed the following problems:
1. no permission (None) and zope.Public within a trusted adapter registration provokes different behavior (example below KeyReferenceToPersistent)
2. the zwiki bug and my related implementations bugs still exists, because regularly folks that registering trusted adapters using <adapter... and <class...do not set
any permission within <adapter.., but only within <class.... (That kind of permission declaration causes the invocation of the regular-trusted-adapter-factory.)
Therefore I reverted 'your' solution back to the first implementation [Revision 30059, 30060]. I assumed that it will be less evil
to do without two different trusted adapters factories (regular (zope.Public and None) and the locating one (other permission)).
+ we can fix the zwiki bug and related implementations bugs easily
+ we can omit the unclear permission-precedence if the <adapter... <class... pattern is used for trusted adapters
o the untrusted adapters with no location get only location-proxied if permission is not None or zope.Public
- we have to derive the KeyReferenceToPersistent adapter from Location to omit the pickle error
Just now I added some optimization [30067]:
Trusted adapters get regularly only protected if the adapted object is protected. Therefore we can omit the location proxy in cases where the trusted adapters get not protected.
I wrote an other adapter factory (PartiallyLocatingTrustedAdapterFactory) which is only using location proxies if the adapter is protected and does not provide ILocation.
If ILocation is provided the parent is still set if None.
And this that solves the KeyRefernceToPersistent problem too. [revison 30068]
Within the current branch there are the three adapter factories:
- PartiallyLocatingTrustedAdapterFactory
- LocatingTrustedAdapterFactory
- TrustedAdapterFactory
You can easily switch them within adapter() directive handler and look for the optimum.
After all I would prefer the current solution. But I know the decision is up to you.
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com