Dominik Huber wrote:
Jim Fulton wrote:
We have the use case that we adapt a lot of additional
functionalities to a pretty stupid content.
Each additional functionality has differentiated permission-sets
comparable to regular content objects. For example different
permissions for reading and setting attributes of the provided
Sure, but I would use different adapters to different functions.
How can you handle the set and read aspects of a schema-based interface
in two different adapters?
You can't unless you use accessors.
The permission is not a discriminator within
the adapter directive.
That's a bureaucratic solution ;)
So at the moment I do not see any another possibility to set those
permissions than using an additional <class.. directive.
All 'bugs' related to this issue (that I'm aware of) including the
zwiki-bug that was reported uses the above pattern and breaks.
The reason for my branch was to solve this kind problem :)
But your original fix caused other problems.
Only if somebody is memorizing (and pickle) adapters. Please be honest,
that's not the most ordinary application.
(at least there were definitely more application using the above
This isn't about the the specific pickling problem. It's about
the unexpected problems from implicitly proxying something.
Proxies are a technology that should be used only when necessary.
This whole discussion is about providing the convenience of
not having to subclass Location in an adapter class when an adapter
is going to be security proxied. While I think this convenience has
value, the value does not justify always adding the location proxy.
2. the resulting adapter requires the permission defined by <class..
IMO case 2. happens (experimental verification only, I do not
understand all magics within _protectedFactory).
The status-quo is pretty implicit too. I looking forward to explain
such stuff to newbies ;)
In this case, the designer needs to do one of:
- Make their adapter class a location
- Factor their adapter into separate adapters that each
do one thing and need a single permission.
I just thought of another alternative in the case of single adapters.
The adapter directive lets you name multiple factories in the factory
attribute. You could list the location proxy constructor as a factory
in the ZCML:
Here, we are *explicitly* saying that we want to combine
an aplication factory with a location proxy.
This works for the example above.
We missed us.
Question: What should the precedence be if I use the sample zwiki
registration (modified example above)?
At the moment (trunk) the permission attribute of the <adapter... is
ignored and the permission-set of the <class... is invoked
(experimental verification only).
I couldn't tell you what the precedence should be because I didn't
anticipate that someone would do both.
Here's what I want:
The adapter directive grows a new feature. If the adapter directive
a permission directive with a permission other than zope.Public and the
adapter adapts one or more objects, then we provide a factory that:
- Adds a location proxy if it doesn't provide ILocation, and
- Sets the __parent__ if the existing value is not None
Dis you implement this?
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
OK, sounds like a bug.
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
Therefore I reverted 'your' solution back to the first implementation
[Revision 30059, 30060].
That's not acceptable
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
I didn't follow all of that...
Just now I added some optimization :
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.
OK, this is an imporovement.
Within the current branch there are the three adapter factories:
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.
This is looking pretty good. When we're done, I'd like to simplify
the code quite a bit. You currently have two classes
that aren't used, TrustedAdapterFactory and LocatingTrustedAdapterFactory.
If we get rod of these, then we can get rid of the mixin.
BTW, from a style point of view, we've moved away from putting
doctests in modules toward separate .txt files (e.g. adapter.txt).
This makes both the documentation and the code easier to read. I
realize you were following the existing style.
I'm happy with a simplified version fo what you have now.
Here are 2 other alternatives to consider:
1. Add a "locate" option to the adapter directive, which
defaults to false. If true (locate="1"), then a location
proxy is always added to the adapter.
2. Option 1 but default to true if a non-public permission is
These alternatives are explicit and hande the case where
permissions are declared in a separate directive.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list