Hi,
Just to confirm that I merged this change into the trunk.
http://svn.zope.org/Products.CMFCore/trunk/Products/CMFCore/?rev=98305&view=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
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 dow
-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 sup
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
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 inform
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Miles wrote:
>
> Hi
>
>
>
> >> 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 t
Hi
>> 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
>
-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
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
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 h
-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 a
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'
Hi Miles!
Miles wrote:
> This change is now done, and checked in on a branch.
Great!
> 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?
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 b
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
Hi!
Miles wrote:
> Hi,
>
>
>
>>> 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
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
___
Zo
Hi,
>> 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 comple
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 adapt
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 rei
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 th
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 diff
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 joini
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 wrapp
Jens Vagelpohl wrote:
> -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 you
Charlie Clark wrote:
> 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
>> enti
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.
-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
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
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, t
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 ther
>> 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
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
Hi!
Miles wrote:
> Thanks for the clarification. The bits that confused me were:
>
> class IndexableObjectSpecification(ObjectSpecificationDescriptor)
> ...
>
> class IndexableObjectWrapper(object):
>
> implements(IIndexableObjectWrapper)
> __providedBy__ = IndexableObjectSpecif
On 3/10/09 1:17 AM, "Charlie Clark" 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
> Helm
Thanks
> Can anyone tell me if it is possible to register an adapter to
> 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 mec
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 IndexableOb
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
-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 pr
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 "
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, th
-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
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 thi
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
-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 accom
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 i
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 ch
-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 iss
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
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 in
Previously Jens Vagelpohl wrote:
> 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 wou
-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
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
-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 ough
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 directl
57 matches
Mail list logo
