Re: [Zope-CMF] IndexableObjectWrapper
Hi, Just to confirm that I merged this change into the trunk. http://svn.zope.org/Products.CMFCore/trunk/Products/CMFCore/?rev=98305view=rev Miles Miles wrote: Hi, Can anyone tell me if it is possible to register an adapter to provide a different IndexableObjectWrapper class from the stock CMF one? There's some sort of framework code that hints that it ought to enable this, but I can't see how! The code still seems to instantiate the wrapper directly using the class, rather than looking it up via the component architecture. Can anyone explain what's going on? I've drawn a blank from googling for examples. Thanks, Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi, - The CatalogTool tests set up the adapter at the moment, as a lot of the catalog tests require the adapter to work properly. This is done in the _makeContent method as it applied to most tests that used the dummy content. However, I think it belongs somewhere else, but I wasn't sure whether that place was a layer, a setup method or somewhere else. Any suggestions? I agree it belongs somewhere else. Maybe a registerWrapper method. But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Agreed. I had expected that the catalog would do a queryAdapter, and default to the existing wrapper class if not found. Makes sense for BBB - it's possible that someone might be inheriting from the Catalog but not loading the adapter registrations, in which case their code would just break. Can I suggest the following logic: 1. if the object already implements the IIndexableObject marker interface, no wrapping is required; 2. otherwise, adapt to IIndexableObject to do the wrapping; 3. if no adapter is registered, fall back to the existing IndexableObjectWrapper class for BBB. In the case of 3, I would like to issue some deprecation warning or log message to alert that a registration is required in future. As 2.2.0 is not yet released, is it possible/desirable to make it a deprecation? Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miles wrote: Hi, - The CatalogTool tests set up the adapter at the moment, as a lot of the catalog tests require the adapter to work properly. This is done in the _makeContent method as it applied to most tests that used the dummy content. However, I think it belongs somewhere else, but I wasn't sure whether that place was a layer, a setup method or somewhere else. Any suggestions? I agree it belongs somewhere else. Maybe a registerWrapper method. But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Agreed. I had expected that the catalog would do a queryAdapter, and default to the existing wrapper class if not found. Makes sense for BBB - it's possible that someone might be inheriting from the Catalog but not loading the adapter registrations, in which case their code would just break. Can I suggest the following logic: 1. if the object already implements the IIndexableObject marker interface, no wrapping is required; 2. otherwise, adapt to IIndexableObject to do the wrapping; 3. if no adapter is registered, fall back to the existing IndexableObjectWrapper class for BBB. That sounds like what I had in mind, but not for BBB. I think of the adapter scheme as a way to choose a non-default wrapper, rather than a quasi-mandatory replacement for it. In the case of 3, I would like to issue some deprecation warning or log message to alert that a registration is required in future. As 2.2.0 is not yet released, is it possible/desirable to make it a deprecation? I wouldn't add a warning for it, because I wouldn't rip out the fallback. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwNqF+gerLs4ltQ4RArehAJ9PSt1zNnJFdKJV/dPx096ZP8y8/wCgmYSF CAD9dshczPrdWP4uf6cnpsQ= =/BUg -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi snip Can I suggest the following logic: 1. if the object already implements the IIndexableObject marker interface, no wrapping is required; 2. otherwise, adapt to IIndexableObject to do the wrapping; 3. if no adapter is registered, fall back to the existing IndexableObjectWrapper class for BBB. That sounds like what I had in mind, but not for BBB. I think of the adapter scheme as a way to choose a non-default wrapper, rather than a quasi-mandatory replacement for it. Ok, well this logic is checked in now on the branch, and tests adjusted accordingly. Without any warnings. Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Miles wrote: And I would prefer a new marker interface 'IIndexableObject'. I guess there are use cases that don't require restricted searchResults based on allowedRolesAndUsers and usually we want to catalog more attributes than just this one. So we need an interface that marks objects that provide all the attributes we want to catalog, not an interface that specifies the available attributes. It's taken several readings for me to understand this, but I think I agree. I've adjusted the registrations so that they are based on a marker interface, IIndexableObject. Sorry. But it looks like you did get my point anyway. If the object already provides this index, no wrapping is carried out. I added some tests for this. I'm afraid there are still different opinions about useful fallbacks. Please see my reply to Tres. I also adjusted the registration to use ICatalogAware rather than IContentish, as that seemed to make more sense. In the long run I'd like to get rid of ICatalogAware. Improving the usage of object events should make it obsolete. The IndexableObjectWrapper doesn't use any features of ICatalogAware, so I can't see a need to use it here. I agree it belongs somewhere else. Maybe a registerWrapper method. But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Ok, I bit the bullet and did some work on the tests. Great! Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Tres Seaver wrote: yuppie wrote: But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Agreed. I had expected that the catalog would do a queryAdapter, and default to the existing wrapper class if not found. Well. I had expected it would default to the unwrapped object. Restricted catalog queries rely on allowedRolesAndUsers, but AFAICS it is not essential for CMFCore that the object is wrapped before cataloged. The current code on the branch requires the new IIndexableObject interface. I'm not sure if we should make it required. It makes things more explicit, but creates an additional burden for simple use cases and unit tests. It should be sufficient to assume that objects without registered adapter are indexable unwrapped. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miles wrote: Hi snip Can I suggest the following logic: 1. if the object already implements the IIndexableObject marker interface, no wrapping is required; 2. otherwise, adapt to IIndexableObject to do the wrapping; 3. if no adapter is registered, fall back to the existing IndexableObjectWrapper class for BBB. That sounds like what I had in mind, but not for BBB. I think of the adapter scheme as a way to choose a non-default wrapper, rather than a quasi-mandatory replacement for it. Ok, well this logic is checked in now on the branch, and tests adjusted accordingly. Without any warnings. Thanks, looks good. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwOUj+gerLs4ltQ4RAolpAKC0o4oox/IYKe4curmEgKFiLnRjqQCg2kd2 Soip97b3h35ItbJhdjKjxNA= =+baG -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Am 18.03.2009 um 13:48 schrieb yuppie: Looks unnecessarily complex to me. But I'm afraid I'm outvoted. I wouldn't say that. From what I've understood of the discussion I tend to favour your position. Unfortunately I don't think I've understood everything well enough to make a really informed decision! I do, however, like the idea of the default adapter. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hello Tres Seaver wrote: Miles wrote: Can I suggest the following logic: 1. if the object already implements the IIndexableObject marker interface, no wrapping is required; If we don't support 3., we can make 'no wrapping' the default. I think this is a change in the way the catalog works - no wrapping is not the default at the moment, and I can imagine some hard to identify bugs appearing if it did change. 2. otherwise, adapt to IIndexableObject to do the wrapping; 3. if no adapter is registered, fall back to the existing IndexableObjectWrapper class for BBB. That sounds like what I had in mind, but not for BBB. I think of the adapter scheme as a way to choose a non-default wrapper, rather than a quasi-mandatory replacement for it. What's the win of providing a default that way? IndexableObjectWrapper contains policy decisions, Plone e.g. doesn't use it. The current code on the branch registers an adapter for IContentish, so CMFDefault will never use that hardcoded default. The change is in a new feature release. People can't expect full BBB if they use customized registrations or catalog content that doesn't implement IContentish. Ok, well this logic is checked in now on the branch, and tests adjusted accordingly. Without any warnings. Thanks, looks good. Looks unnecessarily complex to me. But I'm afraid I'm outvoted. I'm all for providing a fallback so existing unknown sites work well and the behaviour doesn't change, but to be honest I agree with yuppie - it just seems a bit crufty to be there forever. Thinking about it, I'd be concerned that it would mask real errors: Consider if your adapter registration isn't firing for some reason; your objects appear to be being cataloged just fine and it's only weeks later the problem comes to light that a subtly different wrapper was being used. I think either we provide no fallback (i.e. step 3 doesn't exist, it just errors) or it spits out a warning when it uses step 3. Generally, I think the ultimate aim should be just using adapter registrations for this sort of behaviour. Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi! Tres Seaver wrote: Miles wrote: Can I suggest the following logic: 1. if the object already implements the IIndexableObject marker interface, no wrapping is required; If we don't support 3., we can make 'no wrapping' the default. 2. otherwise, adapt to IIndexableObject to do the wrapping; 3. if no adapter is registered, fall back to the existing IndexableObjectWrapper class for BBB. That sounds like what I had in mind, but not for BBB. I think of the adapter scheme as a way to choose a non-default wrapper, rather than a quasi-mandatory replacement for it. What's the win of providing a default that way? IndexableObjectWrapper contains policy decisions, Plone e.g. doesn't use it. The current code on the branch registers an adapter for IContentish, so CMFDefault will never use that hardcoded default. I think that registration should be in CMFDefault, anyway. Applications which haven't updated to this new model should continue to work (including indexing 'allowedRolesAndUsers'). The change is in a new feature release. People can't expect full BBB if they use customized registrations or catalog content that doesn't implement IContentish. Ok, well this logic is checked in now on the branch, and tests adjusted accordingly. Without any warnings. Thanks, looks good. Looks unnecessarily complex to me. But I'm afraid I'm outvoted. Falling back to the current behavior is cheap, both at runtime and in maintenance costs. Why break BBB gratuitously? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwP/e+gerLs4ltQ4RAmr3AJ9vBrqTWDyDo/DSPGjY00p6XIJbvQCgpTW1 9puaqcux8hIdow0DLsFZ4i4= =VeKx -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Tres Seaver wrote: Falling back to the current behavior is cheap, both at runtime and in maintenance costs. Why break BBB gratuitously? Because this would be a simple *generic* solution: w = queryMultiAdapter((obj, self), IIndexableObject, default=obj) That code could be pushed down the stack to ZCatalog and CMF could use that feature by registering a CMF-specific adapter. No need to override the catalog_object method in CatalogTool. And I doubt missing BBB would hurt many people: If you don't include the ZCML files from CMF, you have to update your registrations anyway. And who catalogs content that doesn't implement IContentish? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi, Thanks for the feedback! I think we're pretty much there with this. As there are no adapters in CMFCore at the moment, there's no precedent to follow. So: - The multi-adapter is registered in a new file, implements.zcml Why did you choose the name implements.zcml? I can't see how 'implements' describes the contained registration. I would have used the content.zcml file or added a catalog.zcml file. To be honest, I was just guessing at a pattern to follow, that wouldn't lead to creating a million ZCML files. I'll add it into content.zcml. And I would prefer a new marker interface 'IIndexableObject'. I guess there are use cases that don't require restricted searchResults based on allowedRolesAndUsers and usually we want to catalog more attributes than just this one. So we need an interface that marks objects that provide all the attributes we want to catalog, not an interface that specifies the available attributes. It's taken several readings for me to understand this, but I think I agree. I've adjusted the registrations so that they are based on a marker interface, IIndexableObject. If the object already provides this index, no wrapping is carried out. I added some tests for this. I also adjusted the registration to use ICatalogAware rather than IContentish, as that seemed to make more sense. - The TraversingEventZCMLLayer now also loads implements.zcml, as the correct behaviour of both the catalog and the adapter class is required for the folder tests to pass. - The CatalogTool tests set up the adapter at the moment, as a lot of the catalog tests require the adapter to work properly. This is done in the _makeContent method as it applied to most tests that used the dummy content. However, I think it belongs somewhere else, but I wasn't sure whether that place was a layer, a setup method or somewhere else. Any suggestions? I agree it belongs somewhere else. Maybe a registerWrapper method. But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Ok, I bit the bullet and did some work on the tests. The catalog tests are adjusted to provide their a DummyContent class implementing IIndexableObject, so the adapter is not used. Instead of setting the View permission, the tests set an allowedRolesAndUsers attribute as required. The Folder tests are adjusted to use a DummyCatalog test fixture rather than the real catalog, removing the need for the adapter registration and making the tests a bit simpler, IMO. Otherwise, the branch is here and all the tests pass: /Products.CMFCore/branches/miwa-catalog-adapter/Products/CMFCore Please try to follow PEP 8 and wrap long lines. I think this is done now; I don't think any of the files I touched have lines longer than 79 characters now - but if you do spot one then let me know! Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: - The TraversingEventZCMLLayer now also loads implements.zcml, as the correct behaviour of both the catalog and the adapter class is required for the folder tests to pass. - The CatalogTool tests set up the adapter at the moment, as a lot of the catalog tests require the adapter to work properly. This is done in the _makeContent method as it applied to most tests that used the dummy content. However, I think it belongs somewhere else, but I wasn't sure whether that place was a layer, a setup method or somewhere else. Any suggestions? I agree it belongs somewhere else. Maybe a registerWrapper method. But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Agreed. I had expected that the catalog would do a queryAdapter, and default to the existing wrapper class if not found. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJv+To+gerLs4ltQ4RAvt/AJ9D75eOsZh7FINca9MJsnTU26998gCghu8C TaiqRzwLe2WDoHIqaD7qGhs= =kd1W -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] IndexableObjectWrapper
Hi, This change is now done, and checked in on a branch. As there are no adapters in CMFCore at the moment, there's no precedent to follow. So: - The multi-adapter is registered in a new file, implements.zcml - The TraversingEventZCMLLayer now also loads implements.zcml, as the correct behaviour of both the catalog and the adapter class is required for the folder tests to pass. - The CatalogTool tests set up the adapter at the moment, as a lot of the catalog tests require the adapter to work properly. This is done in the _makeContent method as it applied to most tests that used the dummy content. However, I think it belongs somewhere else, but I wasn't sure whether that place was a layer, a setup method or somewhere else. Any suggestions? Otherwise, the branch is here and all the tests pass: /Products.CMFCore/branches/miwa-catalog-adapter/Products/CMFCore Thanks, Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi, Good point about the Zope version. However, one thing that I'd like an opinion on is whether it's useful to move the handling of workflow variables out of catalog_object and into the IndexableObjectWrapper class? To my mind it seems cleaner to move it, but I'm not sure on the BBB impact. +1 I can't see any additional BBB issues. Who ever uses a customized IndexableObjectWrapper uses also a customized catalog_object method. I'm still not sure if we should just adapt the object or also the portal or the catalog: Registering different adapters for different portals doesn't make much sense to me. If you need portal specific behavior you can register local adapters. Registering different adapters for different kinds of catalogs might be more useful and while 'portal' is a CMF specific concept the catalog itself exists always. The other reason for adapting portal or catalog is that we want to use them inside the adapter. We need some kind of context for looking up stuff like workflow variables. But do we need the portal, the context of the catalog or the context of the object? If the context of the object is sufficient, we don't need a multi-adapter. If we just need the catalog and its context, we still have a generic solution for Zope 2. If we need the portal, we have a CMF-specific solution. My thinking was that, from a given object, we can always get the portal (or indeed whatever object the wrapper needs). Local adapters is the normal route for portal-specific behaviour, so we should stick to that to keep everything in one place. Using a multi-adapter, and adapting the catalog would appear to be sensible - and as you say, could be generic for zope 2 in future. In some sites, I've derived from catalog so as to use the allowedRolesAndUsers and date filtering behaviours in other catalogs within the portal. So I can definitely see a use-case for it. So +1 from me to a multi-adapter on (object, catalog). Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi Martin! Martin Aspeli wrote: yuppie wrote: Martin Aspeli wrote: yuppie wrote: AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Bear in mind that there is a difference between getting the wrapper itself, and getting the value to catalogue for a particular *attribute* of the wrapper (e.g. allowedRolesAndUsers). Why do we need the wrapper? Why can't we look up directly the adapter for the particular attribute? This could work as well. It does make it harder to change the policy en masse for a particular type (you'd need to override all the adapters, say). One reason to do that may be if you have a very simple object that you know exactly how to catalogue, and you don't want the overhead of looking up various adapters. I did have a closer look at this: The right place for looking up attribute specific adapters directly is deep in the ZCatalog code. And it might indeed be overkill to use separate adapters for several attributes of several content types. So now I basically agree with the solution Miles and you did propose. But I still have some questions: Why is IIndexableObjectWrapper in Plone a multi-adapter and not a simple adapter for object? Could we push this further down the stack to the ZCatalog, making it unnecessary to override catalog_object in CMF? AFAICS all CMF-specific stuff could be done inside the wrapper. Still, the important use case, imho, is to make custom indexers for your custom types. I quite like the pattern in plone.indexer where we use an annotation to make a function into an indexer adapter: http://pypi.python.org/pypi/plone.indexer I agree that's an important use case, but looking up IIndexableObjectWrapper based on the object provides already a solution for it. So we have a basic solution inside the framework and hook for plugging in alternative solutions like plone.indexer. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
yuppie wrote: Why is IIndexableObjectWrapper in Plone a multi-adapter and not a simple adapter for object? Some of the indexers need access to the site root. I think the idea was that you could have different adapters in different types of sites by marking the site root, but a single adapter is probably enough. Could we push this further down the stack to the ZCatalog, making it unnecessary to override catalog_object in CMF? AFAICS all CMF-specific stuff could be done inside the wrapper. Maybe. Touching ZCatalog is kinda scary, though. Still, the important use case, imho, is to make custom indexers for your custom types. I quite like the pattern in plone.indexer where we use an annotation to make a function into an indexer adapter: http://pypi.python.org/pypi/plone.indexer I agree that's an important use case, but looking up IIndexableObjectWrapper based on the object provides already a solution for it. So we have a basic solution inside the framework and hook for plugging in alternative solutions like plone.indexer. Yep, I think that's a good idea. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi, snip Could we push this further down the stack to the ZCatalog, making it unnecessary to override catalog_object in CMF? AFAICS all CMF-specific stuff could be done inside the wrapper. Maybe. Touching ZCatalog is kinda scary, though. I think trying to remove catalog_object completely might require significantly more thought. There are lots more ways in which the basic ZCatalog can be used that we need to consider, in contrast to CatalogTool. What happens if you have two catalogs - should they always both apply the same wrappers? What if you want an unwrapped object to be cataloged in one of them? It's making my head hurt ... However, one thing that I'd like an opinion on is whether it's useful to move the handling of workflow variables out of catalog_object and into the IndexableObjectWrapper class? To my mind it seems cleaner to move it, but I'm not sure on the BBB impact. Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Wichert Akkerman wrote at 2009-3-10 10:01 +0100: ... The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. I like BSD more, but could live with LGPL as well. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Miles wrote: Hi, snip Could we push this further down the stack to the ZCatalog, making it unnecessary to override catalog_object in CMF? AFAICS all CMF-specific stuff could be done inside the wrapper. Maybe. Touching ZCatalog is kinda scary, though. I think trying to remove catalog_object completely might require significantly more thought. There are lots more ways in which the basic ZCatalog can be used that we need to consider, in contrast to CatalogTool. What happens if you have two catalogs - should they always both apply the same wrappers? What if you want an unwrapped object to be cataloged in one of them? It's making my head hurt ... It would be an additional hook. If no wrapper is registered the behavior of ZCatalog would be exactly the same as now. But so far we don't have decided to make Zope 2.12 required for CMF 2.2, so we have start with an implementation in CMF. For now I just want to make sure we don't add CMF-specific stuff if we don't need it. However, one thing that I'd like an opinion on is whether it's useful to move the handling of workflow variables out of catalog_object and into the IndexableObjectWrapper class? To my mind it seems cleaner to move it, but I'm not sure on the BBB impact. +1 I can't see any additional BBB issues. Who ever uses a customized IndexableObjectWrapper uses also a customized catalog_object method. I'm still not sure if we should just adapt the object or also the portal or the catalog: Registering different adapters for different portals doesn't make much sense to me. If you need portal specific behavior you can register local adapters. Registering different adapters for different kinds of catalogs might be more useful and while 'portal' is a CMF specific concept the catalog itself exists always. The other reason for adapting portal or catalog is that we want to use them inside the adapter. We need some kind of context for looking up stuff like workflow variables. But do we need the portal, the context of the catalog or the context of the object? If the context of the object is sufficient, we don't need a multi-adapter. If we just need the catalog and its context, we still have a generic solution for Zope 2. If we need the portal, we have a CMF-specific solution. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 03:33 , Martin Aspeli wrote: There are some discussions about licensing going on with the Plone Foundation, but chances are good that it can be licensed in such a way that CMF could adopt it you want. IMHO the licensing issue is of general interest beyond this one software bit. If there are any changes to Plone licensing I'm sure people on this list would be happy if you or someone else could provide some summary, if and when something is being changed :-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2GO0ACgkQRAx5nvEhZLJs9gCgo69+c0mzg4rIjDSO+h2DEUM1 H90AoIEzoTI2kkYlTq/dX483KZFsFBnc =8P7y -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Jens Vagelpohl wrote: Hi Jens, IMHO the licensing issue is of general interest beyond this one software bit. If there are any changes to Plone licensing I'm sure people on this list would be happy if you or someone else could provide some summary, if and when something is being changed :-) Some people including Wichert and Martin are pushing the Plone foundation to allow for an alternative license for Plone packages that are more of a underlying framework/library nature on request. As I see it, chances are good that we'll see this changing within the next few month even. At the moment, the discussion is about whether we (the Plone foundation) should generally allow one or several alternative licenses (- one seems to be the current favorite) and whether this one (if so decided) should be LGPL or BSD(-like). If there would be a strong preference from the CMF community here I'm sure this would be honored in our discussion. Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) Raphael jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2GO0ACgkQRAx5nvEhZLJs9gCgo69+c0mzg4rIjDSO+h2DEUM1 H90AoIEzoTI2kkYlTq/dX483KZFsFBnc =8P7y -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Am 10.03.2009 um 09:14 schrieb Raphael Ritz: If there would be a strong preference from the CMF community here I'm sure this would be honored in our discussion. Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) Actually that is itself a very valid opinion - any company that is interested in software licences prefers as few of them as possible. My preference is always for a no-strings attached licence (ZPL, modifieid BSD, Apache). It's nice to hear that there is some discussion within Plone about licensing. If there is framework code in Plone that might be better placed lower down the stack in CMF then the sooner the better. There is a heap of stuff that could do with refactoring and reengineering along component architecture principles. It is not a little ironic in an open source context that the next release of Plone requires a new release of CMF to which it itself has (hardly?) contributed. This may often be unintentional as Plone developers write libraries for Plone unaware of the problem of backwards licence incompatability - the wrapper for z3c.forms springs to mind - but it is a problem just the same. Concentrating on a content management framework for Zope as the basis for Plone and other approaches is a good thing IMHO. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 09:14 , Raphael Ritz wrote: Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). In the end I hope that whatever decision is being made does not serve to widen the distance between the Plone community and the rest of the Zope universe. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2JqkACgkQRAx5nvEhZLJNMACeJvlVOK8y1hxx5dkyP1pmwP/M fqAAoJXXclf5a7Gy0tDiAhH5db0oCJLU =mIFf -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Previously Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 09:14 , Raphael Ritz wrote: Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. It is, which is why the ZPL has already been rejected as an option: it is pretty much equivalent to the BSD license, which is much more widely accepted. The ZPL is a Zope Foundation-only license, while one goal of this push in Plone is to encourage wider adoption of generic components, even outside of the Zope community where possible. The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). I do not think the Plone Foundation board is willing to consider donating some of its intellectual property to the Zope Foundation. I am already happy they are willing to consider selective relicensing. But that does not need to be a problem: reusable packages such as plone.indexer can be used by CMF even if they are not covered by the ZPL or managed in svn.zope.org, as long as there is the license is acceptable. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Am 10.03.2009 um 10:01 schrieb Wichert Akkerman: The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. Speaking as someone who hasn't written a whole lot of code: BSD. I have a real dislike of the GPL because I think it fails to emphasise the real benefits of open source and it is a real pain if you wish to integrate with other non-GPL stuff whether it's commercial or not. The same discussion came up for Trac a few years ago because of the desire for closer integration with subversion. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. It is, which is why the ZPL has already been rejected as an option: it is pretty much equivalent to the BSD license, which is much more widely accepted. If they are equivalent, why not dual-license? The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. The discussion has been rehashed in several places, but given a choice between pretty much anything and the GPL I'd vote -1 on the GPL. As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). I do not think the Plone Foundation board is willing to consider donating some of its intellectual property to the Zope Foundation. I am already happy they are willing to consider selective relicensing. To me this really sounds like the rift has widened, by a whole lot. It reads like we're happy to base our stuff on yours, but we really don't want to give back. I'm sure it's not meant that way, but it reads like that. But that does not need to be a problem: reusable packages such as plone.indexer can be used by CMF even if they are not covered by the ZPL or managed in svn.zope.org, as long as there is the license is acceptable. That's not the issue I was trying to address. I was specifically talking about putting functionality in the most appropriate part of the stack, meaning moving it further towards the core. If there are bits and pieces that make more sense in the CMF then saying well, just install our package may satisfy users, but developers will continue wasting time maintaining different implementations. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2NA8ACgkQRAx5nvEhZLLy0wCfehi6WBVBHEcwJZXORFpM2tx4 aD4Anip87gouzSsnK/o4jI57ibOjt3YS =dvw+ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Previously Jens Vagelpohl wrote: On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. It is, which is why the ZPL has already been rejected as an option: it is pretty much equivalent to the BSD license, which is much more widely accepted. If they are equivalent, why not dual-license? What would the advantage be? The ZPL is an exercise of license proliferation and as far as I can see gives no benefits over BSD. The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. The discussion has been rehashed in several places, but given a choice between pretty much anything and the GPL I'd vote -1 on the GPL. I made a typo there: the discussion is focusing on LGPL versus BSD. I suspect that will not change your vote though :) As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). I do not think the Plone Foundation board is willing to consider donating some of its intellectual property to the Zope Foundation. I am already happy they are willing to consider selective relicensing. To me this really sounds like the rift has widened, by a whole lot. It reads like we're happy to base our stuff on yours, but we really don't want to give back. I'm sure it's not meant that way, but it reads like that. It is not that way at all. Plone does want to give back, and by relicensing components does exactly that. If the BSD is chosen you can do anything you want with that Plone code, except upload it to svn.zope.org since that implies transferring ownership, which is not allowed. This is no different than Zope policies: you can not copy code from svn.zope.org to the plone repository either. Or move code from Repoze to Zope, from Zope to FSF, etc. etc. The license is not the limiting factor there, but the surrounding policies are. But that does not need to be a problem: reusable packages such as plone.indexer can be used by CMF even if they are not covered by the ZPL or managed in svn.zope.org, as long as there is the license is acceptable. That's not the issue I was trying to address. I was specifically talking about putting functionality in the most appropriate part of the stack, meaning moving it further towards the core. If there are bits and pieces that make more sense in the CMF then saying well, just install our package may satisfy users, but developers will continue wasting time maintaining different implementations. Why would there be multiple implementations if they can just use the existing one? I do not see that. I do agree that work should be in in CMF itself, and this particular instance of the indexable wrappers is an excellent example of that. I hope that in the last few years we have already demonstrated that we really do want to work closer with the CMF and Zope communities. Perhaps in the future the Plone Foundation would be willing to donate code to the Zope Foundation. At this moment that is a bridge too far, and I fear that as soon as I suggest that at this point in time the entire relicensing movement will die in a never-ending debate. Lets save that one for a later day. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Jens Vagelpohl wrote: That's not the issue I was trying to address. I was specifically talking about putting functionality in the most appropriate part of the stack, meaning moving it further towards the core. If there are bits and pieces that make more sense in the CMF then saying well, just install our package may satisfy users, but developers will continue wasting time maintaining different implementations. I think we all agree on this. In retrospect, it would've been a better idea to push for plone.indexer to be a part of CMF. However, I implemented it driven by Plone's release cycle and feature proposal process, which is why it ended up as it did. *I* want this feature for Plone, but it'd be even better if others could benefit. Of course, it's not too late for that. If the license issue can be overcome (and I'm pretty sure that it will by April/May), then CMF can depend on plone.indexer if it so wants, and I'm willing to help make that possible if it means changing plone.indexer or helping with the CMF level implementation. In the future, it may be that we can meet in the middle on this. When the PLIP process kicks off, it'd be good if the CMF developers had a look in as well. We should probably be better at announcing the various deadlines and proposals on this list, but if you guys see something that you feel would be a good fit further down, it doesn't hurt to raise that, lest the developer hasn't thought about it. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 11:08 , Martin Aspeli wrote: I think we all agree on this. In retrospect, it would've been a better idea to push for plone.indexer to be a part of CMF. However, I implemented it driven by Plone's release cycle and feature proposal process, which is why it ended up as it did. *I* want this feature for Plone, but it'd be even better if others could benefit. IMHO the release cycle argument doesn't wash. We've always had CMF releases in preparation for important Plone releases, and I'm happy to continue that. Of course, it's not too late for that. If the license issue can be overcome (and I'm pretty sure that it will by April/May), then CMF can depend on plone.indexer if it so wants, and I'm willing to help make that possible if it means changing plone.indexer or helping with the CMF level implementation. Thanks, I appreciate that. Generally, I think now that the ZF has cleared up the remaining issues about code ownership etc. we finally have two entities, the ZF and the Plone Foundation, that are the perfect platform for official issues like code donations, or for coordinating other cooperation issues. I can't judge how the Plone Foundation acts within the Plone community, but as far as the Zope Foundation goes, Martijn has been doing a lot of work to make it more relevant and an important player in the actual software development process. In the future, it may be that we can meet in the middle on this. When the PLIP process kicks off, it'd be good if the CMF developers had a look in as well. We should probably be better at announcing the various deadlines and proposals on this list, but if you guys see something that you feel would be a good fit further down, it doesn't hurt to raise that, lest the developer hasn't thought about it. Is there any kind of low-traffic announcement list for things like PLIPs? I'm not subscribed to any Plone list because of (for me at least) signal to noise ratio fears. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2PwIACgkQRAx5nvEhZLJs8QCfYsGqkD63R9+isOhA0nXzeWy+ IgoAoJ8xfUzIMdGmlOSXUEreYgF7ErI+ =owJ7 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: That's not the issue I was trying to address. I was specifically talking about putting functionality in the most appropriate part of the stack, meaning moving it further towards the core. If there are bits and pieces that make more sense in the CMF then saying well, just install our package may satisfy users, but developers will continue wasting time maintaining different implementations. Why would there be multiple implementations if they can just use the existing one? I do not see that. For the CMF project it is essential to have full control over its own layer of the stack and to participate in the development of the Zope layer. Using packages from the Plone repository means either using them as a black box or joining the Plone Foundation to participate in their development. IMO both options are not acceptable. I do agree that work should be in in CMF itself, and this particular instance of the indexable wrappers is an excellent example of that. I hope that in the last few years we have already demonstrated that we really do want to work closer with the CMF and Zope communities. For technical reasons this collaboration is asymmetric. Plone is built on top of Zope and CMF, not the other way round. If you want to work really close with these communities, you have to be part of them and use their repository. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Thanks! You already noticed that the wrapper is instantiated directly, so that's what's going on. No magic, no component architecture. Thanks for the clarification. The bits that confused me were: class IndexableObjectSpecification(ObjectSpecificationDescriptor) ... class IndexableObjectWrapper(object): implements(IIndexableObjectWrapper) __providedBy__ = IndexableObjectSpecification() What does this code actually achieve (I get the implements bit, obviously)?! Whether that is good or bad or should be changed is a different issue. I will write up a short proposal. Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Thanks Can anyone tell me if it is possible to register an adapter to snip This should work with plain CMF and be simple to hook into the catalogue tool. (For me) this is the root of the problem - it can only be hooked into the catalog by subclassing at the moment, there is no other mechanism to use different implementations. If there was, then plone.indexer (or whatever) could be used directly. Therefore, can I make a proposal (which I am happy to carry out), as I think this is a desirable change? PROPOSAL: Use CA to look up the indexable object wrapper PROBLEM: It is not possible to provide alternative implementations of the IndexableObjectWrapper class at the moment - this prevents customising the indexing process. SOLUTION: Look up the IndexableObjectWrapper using the Component Architecture. The catalog tool will look up a named utility that creates a wrapped object suitable for indexing. The default implementation of the utility will return the object wrapped using the current IndexableObjectWrapper. If required, Local Site configuration can be used to provide different implementations as needed. BACKWARDS COMPATIBILITY: Any catalog implementation that used a different wrapper class would have to subclass the main catalog and override the relevant function, so will be unaffected by the change. Any thoughts? Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
On 3/10/09 1:17 AM, Charlie Clark char...@begeistert.org wrote: Am 10.03.2009 um 10:01 schrieb Wichert Akkerman: The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. ...: BSD. +2 Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Miles wrote: Thanks for the clarification. The bits that confused me were: class IndexableObjectSpecification(ObjectSpecificationDescriptor) ... class IndexableObjectWrapper(object): implements(IIndexableObjectWrapper) __providedBy__ = IndexableObjectSpecification() What does this code actually achieve (I get the implements bit, obviously)?! This makes the wrapper transparent, allowing the index to look up adapters for the interfaces of the object. TextIndexNG3 works that way. Whether that is good or bad or should be changed is a different issue. I will write up a short proposal. AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Am 10.03.2009 um 10:49 schrieb Wichert Akkerman: Perhaps in the future the Plone Foundation would be willing to donate code to the Zope Foundation. At this moment that is a bridge too far, and I fear that as soon as I suggest that at this point in time the entire relicensing movement will die in a never-ending debate. Lets save that one for a later day. I suspect you're right on that and that we on this list can all say that, with hindsight, the licence debate should never have happened. Let's hope it can be resolved in the future. I hope this will become easier as development moves to a more library-based approach -- all hail TurPlango! What we cannot (dual-)license for the CMF but think we need for the CMF we will have to reimplement. I have to agree with Jens that saying something was added to Plone rather than the CMF because of the Plone release cycle is disingenuous. As long as I have been following the list the CMF releases have been timed for Plone. It would be good to see this change from now on as I suspect the number of core developers on both projects is limited and both projects would benefit from effectively pooled resources and clear ideas of what goes where. I also have to agree with Jens that the Plone mailing lists are way too noisy. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
class IndexableObjectWrapper(object): implements(IIndexableObjectWrapper) __providedBy__ = IndexableObjectSpecification() What does this code actually achieve (I get the implements bit, obviously)?! This makes the wrapper transparent, allowing the index to look up adapters for the interfaces of the object. TextIndexNG3 works that way. Brilliant! Now it all makes sense. Any objections to me adding some comments into IndexableObjectSpecification to this effect? Mile ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
yuppie wrote: Hi! Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: That's not the issue I was trying to address. I was specifically talking about putting functionality in the most appropriate part of the stack, meaning moving it further towards the core. If there are bits and pieces that make more sense in the CMF then saying well, just install our package may satisfy users, but developers will continue wasting time maintaining different implementations. Why would there be multiple implementations if they can just use the existing one? I do not see that. For the CMF project it is essential to have full control over its own layer of the stack and to participate in the development of the Zope layer. Using packages from the Plone repository means either using them as a black box or joining the Plone Foundation to participate in their development. IMO both options are not acceptable. You don't need to join the Plone Foundation to develop packages in svn.plone.org. You *do* need to sign a contributor agreement granting some IP rights over that code to the Plone Foundation, in return for a promise that it will always be available under an open source license. There are no limits on who can sign that agreement or for what purpose they choose to work with the code in that repository. Of course, the same goes for svn.zope.org: you need to sign a document and grant certain rights over your work to the Zope Foundation. If CMF really cannot use packages not in svn.zope.org, then that's a bit sad and will invariably lead to a lot of re-invention rather than re-use. I don't really understand why it is essential to have this level of control over every line of code you use. This is entirely a self-imposed restriction. I do agree that work should be in in CMF itself, and this particular instance of the indexable wrappers is an excellent example of that. I hope that in the last few years we have already demonstrated that we really do want to work closer with the CMF and Zope communities. For technical reasons this collaboration is asymmetric. Plone is built on top of Zope and CMF, not the other way round. If you want to work really close with these communities, you have to be part of them and use their repository. I wrote a package that, I hope, is useful. I am pretty sure it'll work with plain CMF and therefore with other consumers of the CMF, and if doesn't, I'd consider that a bug and fix it. I'm willing to work to make that package a part of the CMF platform, whether optional or fully integrated. To a certain extent, it already is: someone suing the CMF can choose to use plone.indexer in their own project, though they'll need to install it themselves. I don't quite see how this is asymmetric. Rather, it is an outcome of the evolution of this particular package. It's up to the CMF maintainers to decide whether it is desirable to actually adopt this package as part of a standard release. It's not always going to be appropriate (or even if it is, it's not always going to be the case) for every new line of code that *could* be useful to all/most CMF consumers to be built as part of the CMF itself from the outset. If the CMF project has no model for incorporating code from outside its (rather small) community, then I think that is more to the detriment of CMF than to those who created those packages and chose to put the effort in to reduce their dependencies and make them more generally useful. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi Miles, This should work with plain CMF and be simple to hook into the catalogue tool. (For me) this is the root of the problem - it can only be hooked into the catalog by subclassing at the moment, there is no other mechanism to use different implementations. If there was, then plone.indexer (or whatever) could be used directly. Therefore, can I make a proposal (which I am happy to carry out), as I think this is a desirable change? PROPOSAL: Use CA to look up the indexable object wrapper +1 - Plone already has this, and it's pretty easy to do. If CMF got this, then Plone could drop its own custom adapter and use the CMF one to hook in plone.indexer, as could anyone else wanting to use this package. PROBLEM: It is not possible to provide alternative implementations of the IndexableObjectWrapper class at the moment - this prevents customising the indexing process. SOLUTION: Look up the IndexableObjectWrapper using the Component Architecture. The catalog tool will look up a named utility that creates a wrapped object suitable for indexing. Actually, I'd suggest you look it up as an adapter on the object being indexed. Also, it probably shouldn't be named, as there's nothing to switch the name on. The default implementation of the utility will return the object wrapped using the current IndexableObjectWrapper. If required, Local Site configuration can be used to provide different implementations as needed. BACKWARDS COMPATIBILITY: Any catalog implementation that used a different wrapper class would have to subclass the main catalog and override the relevant function, so will be unaffected by the change. Any thoughts? +1 in general Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 11:08 , Martin Aspeli wrote: I think we all agree on this. In retrospect, it would've been a better idea to push for plone.indexer to be a part of CMF. However, I implemented it driven by Plone's release cycle and feature proposal process, which is why it ended up as it did. *I* want this feature for Plone, but it'd be even better if others could benefit. IMHO the release cycle argument doesn't wash. We've always had CMF releases in preparation for important Plone releases, and I'm happy to continue that. I'm not arguing. I'm saying that it didn't really cross my mind, because I was improving something that was already Plone specific (the ExtensibleIndexableObjectWrapper) in response to a Plone demand and working towards a Plone deadline. Hindsight is a good thing, and maybe it would've been better to try to all of it down into the stack. In this case, I didn't. Except that I kind of did... I created a package with no other Plone dependencies, in the hope that it *could* be useful. I didn't take the time to discuss it on this list, which I should have. However, the desire for it to be re-usable by other CMF consumers is clearly in evidence. Of course, it's not too late for that. If the license issue can be overcome (and I'm pretty sure that it will by April/May), then CMF can depend on plone.indexer if it so wants, and I'm willing to help make that possible if it means changing plone.indexer or helping with the CMF level implementation. Thanks, I appreciate that. Generally, I think now that the ZF has cleared up the remaining issues about code ownership etc. we finally have two entities, the ZF and the Plone Foundation, that are the perfect platform for official issues like code donations, or for coordinating other cooperation issues. I can't judge how the Plone Foundation acts within the Plone community, but as far as the Zope Foundation goes, Martijn has been doing a lot of work to make it more relevant and an important player in the actual software development process. Indeed! Bear in mind that the Plone Foundation has an explicit goal *not* to interfere with software development. However, it does deal with issues of IP and so I agree the two foundations are the right forum for this type of thing. In the future, it may be that we can meet in the middle on this. When the PLIP process kicks off, it'd be good if the CMF developers had a look in as well. We should probably be better at announcing the various deadlines and proposals on this list, but if you guys see something that you feel would be a good fit further down, it doesn't hurt to raise that, lest the developer hasn't thought about it. Is there any kind of low-traffic announcement list for things like PLIPs? I'm not subscribed to any Plone list because of (for me at least) signal to noise ratio fears. There's plone-announce, but I don't think this was announced there. I actually think the Plone release manager should cross-post a few important announcements to this list, though. The actual feature discussion happens on the medium-traffic framework-team list, which you can join. In fact, it'd be great if you did, as we'd appreciate your input, but I realise it may not be something you want to spend a lot of time on. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 14:21 , Martin Aspeli wrote: The actual feature discussion happens on the medium-traffic framework-team list, which you can join. In fact, it'd be great if you did, as we'd appreciate your input, but I realise it may not be something you want to spend a lot of time on. I'll join, sure. Joining does not imply activity beyond reading ;-) If there was a narrow-scoped announce-type list that contains announcements like PLIPs or important development decisions that may be of interest to the CMF developers as well then it would be useful to pipe it into this list. That's one reason I asked. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2bQkACgkQRAx5nvEhZLKP4wCeK5mW5+r4Ie0s1sghrz20zqWG gDgAnjQelFAI2qdpRiZMCog+JpCIGW0s =JEV8 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Martin Aspeli wrote: Jens Vagelpohl wrote: Is there any kind of low-traffic announcement list for things like PLIPs? I'm not subscribed to any Plone list because of (for me at least) signal to noise ratio fears. There's plone-announce, but I don't think this was announced there. plone-announce is targeted at consumers of Plone, so has information like New Symposium coming up, Plone 3.2 released. I actually think the Plone release manager should cross-post a few important announcements to this list, though. We could probably do that. There is a lot of information which isn't relevant at all to the CMF level nor the Zope level in the same ways. The actual feature discussion happens on the medium-traffic framework-team list, which you can join. In fact, it'd be great if you did, as we'd appreciate your input, but I realise it may not be something you want to spend a lot of time on. One way to get quite a filtered list is to look at the PLIP's themselves from time to time. For Plone 3.3 this is: http://plone.org/products/plone/releases/3.3 We can make sure to post the important dates for our release process to this list and provide at least this kind of URL. For Plone 4.0 we haven't probably started the process yet (my fault) but have some things available in the listing at: http://dev.plone.org/plone/milestone/4.0 The items on the 4.0 list here are basically all of my personal pet peeves and there's a lot of more things we are going to do, like completely revamp the admin UI and probably use Dexterity for the default types, while retaining backwards compatible support with Archetypes. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
yuppie wrote: AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Bear in mind that there is a difference between getting the wrapper itself, and getting the value to catalogue for a particular *attribute* of the wrapper (e.g. allowedRolesAndUsers). The CatalogTool subclass in Plone solves the former. plone.indexer uses the hook it puts in place to solve the latter. I think at a minimum, CMF should just make the whole wrapper swappable by looking it up as an adapter. Then people could choose to use plone.indexer if they so needed (we'd obviously need to change plone.indexer to provide an appropriate adapter based on a CMF interface rather than a Plone one, and then deprecate the Plone version). For smaller applications, it may just be unnecessary complexity. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi Martin! Martin Aspeli wrote: yuppie wrote: For the CMF project it is essential to have full control over its own layer of the stack and to participate in the development of the Zope layer. Using packages from the Plone repository means either using them as a black box or joining the Plone Foundation to participate in their development. IMO both options are not acceptable. You don't need to join the Plone Foundation to develop packages in svn.plone.org. You *do* need to sign a contributor agreement granting some IP rights over that code to the Plone Foundation, in return for a promise that it will always be available under an open source license. There are no limits on who can sign that agreement or for what purpose they choose to work with the code in that repository. Of course, the same goes for svn.zope.org: you need to sign a document and grant certain rights over your work to the Zope Foundation. If CMF really cannot use packages not in svn.zope.org, then that's a bit sad and will invariably lead to a lot of re-invention rather than re-use. I don't really understand why it is essential to have this level of control over every line of code you use. This is entirely a self-imposed restriction. Just to make it clear: I'm talking about the code in the CMF and the Zope layer. Not about lower level layers. I'm absolutely fine with having Python and some other libraries in different repositories. And I'm not talking about CMF users. I'm sure there are good reasons to use Plone libraries together with the CMF. I'm talking about closely related code. Maintaining it in different repositories with different code ownership, license and policies creates extra costs. Either everybody has to work in both repositories or you have to ask people to make changes are releases. Refactoring code across repository boundaries becomes almost impossible. For technical reasons this collaboration is asymmetric. Plone is built on top of Zope and CMF, not the other way round. If you want to work really close with these communities, you have to be part of them and use their repository. I wrote a package that, I hope, is useful. I am pretty sure it'll work with plain CMF and therefore with other consumers of the CMF, and if doesn't, I'd consider that a bug and fix it. I'm willing to work to make that package a part of the CMF platform, whether optional or fully integrated. To a certain extent, it already is: someone suing the CMF can choose to use plone.indexer in their own project, though they'll need to install it themselves. I don't quite see how this is asymmetric. Rather, it is an outcome of the evolution of this particular package. It's up to the CMF maintainers to decide whether it is desirable to actually adopt this package as part of a standard release. It's not always going to be appropriate (or even if it is, it's not always going to be the case) for every new line of code that *could* be useful to all/most CMF consumers to be built as part of the CMF itself from the outset. If the CMF project has no model for incorporating code from outside its (rather small) community, then I think that is more to the detriment of CMF than to those who created those packages and chose to put the effort in to reduce their dependencies and make them more generally useful. I don't think it's the role of the CMF project to integrate all the code that could be useful for people building applications. Others like Plone can do that much better. The CMF has to become simpler, not more complex. Third party products always add complexity. Incorporating new code means replacing old code in a backwards compatible way, not just adding another hook. Code evolution is useful, but it can't replace discussions and consolidation. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Martin Aspeli wrote: yuppie wrote: AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Bear in mind that there is a difference between getting the wrapper itself, and getting the value to catalogue for a particular *attribute* of the wrapper (e.g. allowedRolesAndUsers). Why do we need the wrapper? Why can't we look up directly the adapter for the particular attribute? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] IndexableObjectWrapper
Hi, Can anyone tell me if it is possible to register an adapter to provide a different IndexableObjectWrapper class from the stock CMF one? There's some sort of framework code that hints that it ought to enable this, but I can't see how! The code still seems to instantiate the wrapper directly using the class, rather than looking it up via the component architecture. Can anyone explain what's going on? I've drawn a blank from googling for examples. Thanks, Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 9, 2009, at 21:09 , Miles wrote: Can anyone tell me if it is possible to register an adapter to provide a different IndexableObjectWrapper class from the stock CMF one? There's some sort of framework code that hints that it ought to enable this, but I can't see how! The code still seems to instantiate the wrapper directly using the class, rather than looking it up via the component architecture. Can anyone explain what's going on? I've drawn a blank from googling for examples. You already noticed that the wrapper is instantiated directly, so that's what's going on. No magic, no component architecture. Whether that is good or bad or should be changed is a different issue. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm1igUACgkQRAx5nvEhZLLXDgCgkfCiB2OLW/G2LxT1JVBOtGJJ b3gAniLMUd22poUykxudnvXA5ibaK2hO =GZpO -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Previously Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 9, 2009, at 21:09 , Miles wrote: Can anyone tell me if it is possible to register an adapter to provide a different IndexableObjectWrapper class from the stock CMF one? There's some sort of framework code that hints that it ought to enable this, but I can't see how! The code still seems to instantiate the wrapper directly using the class, rather than looking it up via the component architecture. Can anyone explain what's going on? I've drawn a blank from googling for examples. You already noticed that the wrapper is instantiated directly, so that's what's going on. No magic, no component architecture. Whether that is good or bad or should be changed is a different issue. Martin Aspeli implemented an adapter based index wrapper for Plone 3.3. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 9, 2009, at 22:47 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: On Mar 9, 2009, at 21:09 , Miles wrote: Can anyone tell me if it is possible to register an adapter to provide a different IndexableObjectWrapper class from the stock CMF one? You already noticed that the wrapper is instantiated directly, so that's what's going on. No magic, no component architecture. Whether that is good or bad or should be changed is a different issue. Martin Aspeli implemented an adapter based index wrapper for Plone 3.3. It's nice to see that Plone has it, but that doesn't help anyone working off the CMF itself. I wish there was more communication to determine where improvements fit best. Not knowing how Plone implemented it I would make a guess this one small item would have been better off in the CMF itself. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm1lR8ACgkQRAx5nvEhZLJJvQCgnWpvHGu9TUCWOI5kmOzhRWAv X8kAnAvVgxARYBlafyTF9FbosZZgO2Nn =b1rx -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Miles wrote: Hi, Can anyone tell me if it is possible to register an adapter to provide a different IndexableObjectWrapper class from the stock CMF one? There's some sort of framework code that hints that it ought to enable this, but I can't see how! The code still seems to instantiate the wrapper directly using the class, rather than looking it up via the component architecture. Can anyone explain what's going on? I've drawn a blank from googling for examples. In plain CMF, probably not. In Plone, we have a custom CatalogTool which does let you provide a new wrapper wholesale based on object type. In Plone 3.3, we'll *also* have a means of providing individual *attributes* of the wrapper via adapters. See http://pypi.python.org/pypi/plone.indexer. This package should work with stock CMF (though you'll need to wire it into the catalog tool yourself). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 9, 2009, at 22:47 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: On Mar 9, 2009, at 21:09 , Miles wrote: Can anyone tell me if it is possible to register an adapter to provide a different IndexableObjectWrapper class from the stock CMF one? You already noticed that the wrapper is instantiated directly, so that's what's going on. No magic, no component architecture. Whether that is good or bad or should be changed is a different issue. Martin Aspeli implemented an adapter based index wrapper for Plone 3.3. It's nice to see that Plone has it, but that doesn't help anyone working off the CMF itself. I wish there was more communication to determine where improvements fit best. Not knowing how Plone implemented it I would make a guess this one small item would have been better off in the CMF itself. Point taken! Back in the day (before Plone 3.0), Alec Mitchell and I implemented a simple wrapper adapter that lets you look up a different version of the IndexableObjectWrapper. However, this wasn't terribly useful, because it seems what people want is not to replace the wrapper wholesale, but to provide different 'indexers' for specific catalogued attributes on a per-type basis. Even before that, Plone had its own ExtensibleIndexableObjectWrapper that let you add 'getters' for attributes on the wrapper via module level imports. This has worked well, except that there's no way to make particular indexers work only on one particular content type. In Plone 3.3, with the plone.indexer package, we've changed this so that you can add new 'getters' to the standard IOW via adapters. This is in the plone.indexer package: http://pypi.python.org/pypi/plone.indexer This should work with plain CMF and be simple to hook into the catalogue tool. There are some discussions about licensing going on with the Plone Foundation, but chances are good that it can be licensed in such a way that CMF could adopt it you want. Doing so should be simple, even, and I'd be willing to help make this happen. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests