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
-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
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
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
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
-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;
Summary of messages to the cmf-tests list.
Period Tue Mar 17 12:00:00 2009 UTC to Wed Mar 18 12:00:00 2009 UTC.
There were 6 messages: 6 from CMF Tests.
Tests passed OK
---
Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux
From: CMF Tests
Date: Tue Mar 17 21:52:12 EDT 2009
URL:
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
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
Hi,
We have quite a lot of copy-and-paste code here in order to support
using a custom MemberData class for members in particular sites.
The reason for this is that the only way to use a different MemberData
class is to provide a custom wrapUser method.
I'd like to propose that this is
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 18, 2009, at 16:23 , Miles wrote:
Hi,
We have quite a lot of copy-and-paste code here in order to support
using a custom MemberData class for members in particular sites.
The reason for this is that the only way to use a different
Previously Miles wrote:
We have quite a lot of copy-and-paste code here in order to support
using a custom MemberData class for members in particular sites.
The reason for this is that the only way to use a different MemberData
class is to provide a custom wrapUser method.
I'd like to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 18, 2009, at 16:12 , Wichert Akkerman wrote:
Previously Miles wrote:
We have quite a lot of copy-and-paste code here in order to support
using a custom MemberData class for members in particular sites.
The reason for this is that the
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
Hi,
We have quite a lot of copy-and-paste code here in order to support
using a custom MemberData class for members in particular sites.
The reason for this is that the only way to use a different MemberData
class is to provide a custom wrapUser method.
I'd like to propose that this is
16 matches
Mail list logo
