Re: [Zope-CMF] IndexableObjectWrapper

2009-03-23 Thread Miles
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

2009-03-18 Thread Miles
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

2009-03-18 Thread Tres Seaver
-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

2009-03-18 Thread Miles
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

2009-03-18 Thread yuppie
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

2009-03-18 Thread yuppie
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

2009-03-18 Thread Tres Seaver
-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

2009-03-18 Thread Charlie Clark

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

2009-03-18 Thread Miles
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

2009-03-18 Thread Tres Seaver
-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

2009-03-18 Thread yuppie
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

2009-03-17 Thread Miles
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

2009-03-17 Thread Tres Seaver
-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

2009-03-16 Thread Miles
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

2009-03-13 Thread Miles
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

2009-03-11 Thread yuppie
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

2009-03-11 Thread Martin Aspeli
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

2009-03-11 Thread Miles
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

2009-03-11 Thread Dieter Maurer
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

2009-03-11 Thread yuppie
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

2009-03-10 Thread Jens Vagelpohl
-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

2009-03-10 Thread Raphael Ritz
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

2009-03-10 Thread Charlie Clark

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

2009-03-10 Thread Jens Vagelpohl
-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

2009-03-10 Thread Wichert Akkerman
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

2009-03-10 Thread Charlie Clark

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

2009-03-10 Thread Jens Vagelpohl
-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

2009-03-10 Thread Wichert Akkerman
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

2009-03-10 Thread Martin Aspeli
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

2009-03-10 Thread Jens Vagelpohl
-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

2009-03-10 Thread yuppie
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

2009-03-10 Thread Miles
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

2009-03-10 Thread Miles
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

2009-03-10 Thread Andrew Sawyers
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

2009-03-10 Thread yuppie
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

2009-03-10 Thread Charlie Clark

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

2009-03-10 Thread Miles
 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

2009-03-10 Thread Martin Aspeli
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

2009-03-10 Thread Martin Aspeli
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

2009-03-10 Thread Martin Aspeli
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

2009-03-10 Thread Jens Vagelpohl
-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

2009-03-10 Thread Hanno Schlichting
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

2009-03-10 Thread Martin Aspeli
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

2009-03-10 Thread yuppie
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

2009-03-10 Thread yuppie
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

2009-03-09 Thread Miles
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

2009-03-09 Thread Jens Vagelpohl
-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

2009-03-09 Thread Wichert Akkerman
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

2009-03-09 Thread Jens Vagelpohl
-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

2009-03-09 Thread Martin Aspeli
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

2009-03-09 Thread Martin Aspeli
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