On 6/29/09 5:11 PM, Ross Patterson wrote:
Wichert Akkerman<[email protected]>
Sure, but my point is that this shoudl not be necessary. Why should we
force developers to both register a marker interface and an adapter?
That is the kind of extra repetition and extra work that we are now
working hard on removing from Plone.
In this case we are trying to support the capacity to adapt content to a
membrane interface as well as to allow the content to provide it
directly. If we want to have it both ways, then I think this repetition
is appropriate.
I don't see why. The previous approach managed to handle both cases
without repetition, and both my suggestions don't need any form of
repetition either, without loss of any functionality.
Plone offers a fairly rich system of catalog indexing helper routines
which we can leverage. Instead of iterating over the ZCA registrations
to build a list of interface an object implements or can be adapted to
we can do simpler things. For example we could have a feature catalog
that looks like this:
With the current implementation, we don't iterate over the ZCA
registrations, we lookup interfaces that have been registered as
providing the IMembraneQueryableInterface.
@indexer(Interface, membrane_tool.IMembraneTool)
def features(obj):
_features = dict(user = IMembraneUserObject,
auth = IMembraneUserAuth,
props = IMebraneUserProperties)
result=[]
for (ft, iface) in _features.items():
a=iface(obj, None)
if a is not None:
result.append(ft)
return ft
This should be fast enough for indexing purposes since we can use all
the fast paths and optimisations from the ZCA, and gives us much
simpler catalog data: we will no longer need to index all the
interfaces that are not relevant for membrane. There is an obvious
optimization here: if an object does not adapt to IMembraneUserObject
we can short-circuit and stop processing immediately.
My main comment about this I forgot to include. This implementation
still looks up the adapters which I believe was a significant part of
the performance problem before. At any rate, it not only looks up the
adapters, but actually calls the factory as well. Since the factory is
arbitrary code, this is too large a performance *risk*.
The old code was incredibly painful since it essentially did a slow
iteration over all adapter registrations and manually tested every
adapter to see if it applies to the current object. It's a bit similar
to doing a getAdapter for every possible adapter. This version does
between 1 and 4 adapter calls, each of which should be quite fast since
we can use the normal ZCA infrastructure. If that is slow than we have
much much bigger problems, since Plone uses dozens if not hundreds of
adapter calls for every request.
Have you ever seen an adapter constructor that did more than set a few
instance variables to the parameters passed in? I don't consider that
risk to be realistic, or very problematic since it is trivially worked
around.
I think our opinions are pretty firmly rooted and not likely to change.
I'ld like to hear some other opinions on this as well!
Wichert.
--
Archive:
http://www.coactivate.org/projects/remember/lists/remember/archive/2009/06/1246288923750
To unsubscribe send an email with subject "unsubscribe" to
[email protected]. Please contact [email protected] for
questions.
