Wichert Akkerman <[email protected]> writes: > On 6/29/09 4:49 PM, Ross Patterson wrote: >> Wichert Akkerman<[email protected]> writes: >> >>> I am just catching up on Ross's work last week, and I am not sure >>> about the changes in this changeset: >>> >>> http://dev.plone.org/old/collective/changeset/88642/Products.membrane> >> This changeset was proposed and discussed well in advance. It would >> have been vastly preferable to bring up debate *before* a contributor >> put the time in to implement. > > I was not aware of it. I looked a while ago and could not find a > membrane mailinglist anywhere, so I don't think I can be blamed for > that. Even today there is no mention at all in the membrane package > that the remember list is used for membrane development.
On http://plone.org/products/membrane the "Support" link points to the remember list. I'll add an explicit mention into the package as well. >>> I see the problem Ross is trying to solve: generating a list of >>> everything an object can be adapted to is expensive (which is why the >>> same thing was removed from the Plone 3.x tree just before 3.0). >>> >>> This solution moves the penalty to the developer: instead of only >>> having to write an adapter developers are now forced to register both >>> an adapter and a new marker interface. I feel quite strongly that this >>> repetition is not desirable, so I want to investigate alternatives. >> >> If by "register" you mean the "<interface>" registration, the developer >> would not need to do that. All the developer would need to do is make >> sure the class implements the marker interface which can be done in the >> class level implements declaration or in ZCML. This is one of the most >> simple declarations possible. > > 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. >>> 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*. Ross -- Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2009/06/1246288328839 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
