Mailing List Archive

[dev] CatalogTool as utility
Hi!


Converting the CatalogTool is not so easy because it is just a small
subclass of ZCatalog. And ZCatalog expects REQUEST in its acquisition
context.

AFAICS the only place where this causes trouble is the
AbstractCatalogBrain API. But I might be missing other issues. Maybe
some people can test CMF trunk with their code? Is there a Plone branch
that is tested against CMF trunk?

Currently CMF trunk contains some hacks to work around the catalog brain
issues. But I hope there is a better solution. Maybe the ICatalogBrain
methods getURL, _unrestrictedGetObject and getObject should have a
REQUEST argument that is used instead of self.REQUEST?

Any kind of feedback and help is welcome.


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
On Mon, Sep 19, 2011 at 11:57 AM, yuppie <y.2011@wcm-solutions.de> wrote:
> Is there a Plone branch
> that is tested against CMF trunk?

Their isn't a branch. Plone doesn't follow any moving targets from its
lower stack. It always needs someone to sign-up for the job of
updating and then dealing with all issues that the upgrade causes.
Currently Plone most definitely won't pass all tests when run against
CMF trunk - but it's unknown how much breakage there is.

> Currently CMF trunk contains some hacks to work around the catalog brain
> issues. But I hope there is a better solution. Maybe the ICatalogBrain
> methods getURL, _unrestrictedGetObject and getObject should have a
> REQUEST argument that is used instead of self.REQUEST?
>
> Any kind of feedback and help is welcome.

Mmh, why don't we just use zope.globalrequest in ZCatalog directly?
And create a new ZCatalog 2.14 release series with this. Then we don't
have to wait for Zope 4.0 to include it.

Hanno
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
Hi!


Hanno Schlichting wrote:
> On Mon, Sep 19, 2011 at 11:57 AM, yuppie<y.2011-E2EsyBC0hj3+aS/vkh9bjw@public.gmane.org> wrote:
>> Currently CMF trunk contains some hacks to work around the catalog brain
>> issues. But I hope there is a better solution. Maybe the ICatalogBrain
>> methods getURL, _unrestrictedGetObject and getObject should have a
>> REQUEST argument that is used instead of self.REQUEST?
>>
>> Any kind of feedback and help is welcome.
>
> Mmh, why don't we just use zope.globalrequest in ZCatalog directly?
> And create a new ZCatalog 2.14 release series with this. Then we don't
> have to wait for Zope 4.0 to include it.

Using an explicit argument is always cleaner than using
zope.globalrequest. And getObject() already has a (currently unused)
REQUEST argument. And we might be able to provide a migration path for
the API change: If we don't use registerToolInterface, we don't have to
change getObject/getURL calls in places where we still use getToolByName.

But with zope.globalrequest we can avoid modifying the API. So if it is
fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might
be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF?


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
On Mon, Sep 19, 2011 at 3:56 PM, yuppie <y.2011@wcm-solutions.de> wrote:
> But with zope.globalrequest we can avoid modifying the API. So if it is
> fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might
> be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF?

I meant ZCatalog 2.14 only for CMF.

Having independent distributions allows us to evolve them at a different pace :)

Hanno
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
On 19 September 2011 14:56, yuppie <y.2011@wcm-solutions.de> wrote:

> Hi!
>
>
> Hanno Schlichting wrote:
> > On Mon, Sep 19, 2011 at 11:57 AM, yuppie<y.2011-E2EsyBC0hj3+aS/
> vkh9bjw@public.gmane.org> wrote:
> >> Currently CMF trunk contains some hacks to work around the catalog brain
> >> issues. But I hope there is a better solution. Maybe the ICatalogBrain
> >> methods getURL, _unrestrictedGetObject and getObject should have a
> >> REQUEST argument that is used instead of self.REQUEST?
> >>
> >> Any kind of feedback and help is welcome.
> >
> > Mmh, why don't we just use zope.globalrequest in ZCatalog directly?
> > And create a new ZCatalog 2.14 release series with this. Then we don't
> > have to wait for Zope 4.0 to include it.
>
> Using an explicit argument is always cleaner than using
> zope.globalrequest. And getObject() already has a (currently unused)
> REQUEST argument. And we might be able to provide a migration path for
> the API change: If we don't use registerToolInterface, we don't have to
> change getObject/getURL calls in places where we still use getToolByName.
>
> But with zope.globalrequest we can avoid modifying the API. So if it is
> fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might
> be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF?
>
>
getURL() is an extremely common operation, and is often called in TALES
expressions.

-100 on making it take a mandatory request parameter when there are other
solutions available.

Martin
Re: [dev] CatalogTool as utility [ In reply to ]
Hi Hanno!


Hanno Schlichting wrote:
> On Mon, Sep 19, 2011 at 3:56 PM, yuppie<y.2011-E2EsyBC0hj3+aS/vkh9bjw@public.gmane.org> wrote:
>> But with zope.globalrequest we can avoid modifying the API. So if it is
>> fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might
>> be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF?
>
> I meant ZCatalog 2.14 only for CMF.
>
> Having independent distributions allows us to evolve them at a different pace :)

But an additional ZCatalog branch is an additional maintenance burden.
And the required change is small and 100% backwards compatible. The
zope.globalrequest dependency could be made optional.

Do we really need an extra ZCatalog branch for that?


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
On Tue, Sep 20, 2011 at 12:19 PM, yuppie <y.2011@wcm-solutions.de> wrote:
> But an additional ZCatalog branch is an additional maintenance burden.
> And the required change is small and 100% backwards compatible. The
> zope.globalrequest dependency could be made optional.
>
> Do we really need an extra ZCatalog branch for that?

If there's a completely backwards compatible way of doing, we should do that.

I was under the impression, that we had to do an API change for some
methods and add a new request argument to those. If that argument is
required depending on how the tool was retrieved, that's confusing to
me and I'd rather go the zope.globalrequest route.

Hanno
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
Hi!


Hanno Schlichting wrote:
> On Tue, Sep 20, 2011 at 12:19 PM, yuppie<y.2011-E2EsyBC0hj3+aS/vkh9bjw@public.gmane.org> wrote:
>> But an additional ZCatalog branch is an additional maintenance burden.
>> And the required change is small and 100% backwards compatible. The
>> zope.globalrequest dependency could be made optional.
>>
>> Do we really need an extra ZCatalog branch for that?
>
> If there's a completely backwards compatible way of doing, we should do that.
>
> I was under the impression, that we had to do an API change for some
> methods and add a new request argument to those. If that argument is
> required depending on how the tool was retrieved, that's confusing to
> me and I'd rather go the zope.globalrequest route.

I no longer consider modifying ICatalogBrain. The big advantage of using
zope.globalrequest is that we can move forward without discussing API
changes.

I plan to use zope.globalrequest as fallback if self.REQUEST is not
available.

What's the best approach for the five.globalrequest dependency? Just use
zope.globalrequest if it is available? Or specify it in extras_require?
Or add it to install_requires, making it an indirect dependency of the
next Zope 2.13 release?


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
On Wed, Sep 21, 2011 at 1:57 PM, yuppie <y.2011@wcm-solutions.de> wrote:
> I plan to use zope.globalrequest as fallback if self.REQUEST is not
> available.
>
> What's the best approach for the five.globalrequest dependency? Just use
> zope.globalrequest if it is available? Or specify it in extras_require?
> Or add it to install_requires, making it an indirect dependency of the
> next Zope 2.13 release?

Adding it to the setup.py of what project?

I consider using zope.globalrequest as a feature change - primarily
because its interaction with tests is a bit unclear. Introducing more
module global state for the request variable will probably lead to
some changes to test isolation code somewhere.

So in Zope itself, this can only go into trunk. For CMF 2.3, I'd just
put it as a hard dependency into install_requires.

Hanno
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
On 21 September 2011 13:19, Hanno Schlichting <hanno@hannosch.eu> wrote:
> On Wed, Sep 21, 2011 at 1:57 PM, yuppie <y.2011@wcm-solutions.de> wrote:
>> I plan to use zope.globalrequest as fallback if self.REQUEST is not
>> available.
>>
>> What's the best approach for the five.globalrequest dependency? Just use
>> zope.globalrequest if it is available? Or specify it in extras_require?
>> Or add it to install_requires, making it an indirect dependency of the
>> next Zope 2.13 release?
>
> Adding it to the setup.py of what project?
>
> I consider using zope.globalrequest as a feature change - primarily
> because its interaction with tests is a bit unclear. Introducing more
> module global state for the request variable will probably lead to
> some changes to test isolation code somewhere.
>
> So in Zope itself, this can only go into trunk. For CMF 2.3, I'd just
> put it as a hard dependency into install_requires.

The dependency needs to be on five.globalrequest to work with zope2.

Laurence
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
Hi!


Hanno Schlichting wrote:
> On Wed, Sep 21, 2011 at 1:57 PM, yuppie<y.2011-E2EsyBC0hj3+aS/vkh9bjw@public.gmane.org> wrote:
>> I plan to use zope.globalrequest as fallback if self.REQUEST is not
>> available.
>>
>> What's the best approach for the five.globalrequest dependency? Just use
>> zope.globalrequest if it is available? Or specify it in extras_require?
>> Or add it to install_requires, making it an indirect dependency of the
>> next Zope 2.13 release?
>
> Adding it to the setup.py of what project?

I meant Products.ZCatalog.

> I consider using zope.globalrequest as a feature change - primarily
> because its interaction with tests is a bit unclear. Introducing more
> module global state for the request variable will probably lead to
> some changes to test isolation code somewhere.
>
> So in Zope itself, this can only go into trunk. For CMF 2.3, I'd just
> put it as a hard dependency into install_requires.

Ok. Products.CMFCore trunk already has a hard dependency.

My checkin for Products.ZCatalog has an optional dependency on
five.globalrequest. If five.globalrequest is not installed,
Products.ZCatalog behaves exactly as before. I hope we don't need a
Products.ZCatalog 2.14 release for that. Zope 2.13 can use it without
five.globalrequest.

See http://svn.zope.org/?rev=122892&view=rev

Is that ok? Should I add an explicit extra in the setup.py of
Products.ZCatalog?


Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [dev] CatalogTool as utility [ In reply to ]
On Thu, Sep 22, 2011 at 3:14 PM, yuppie <y.2011@wcm-solutions.de> wrote:
> My checkin for Products.ZCatalog has an optional dependency on
> five.globalrequest. If five.globalrequest is not installed,
> Products.ZCatalog behaves exactly as before. I hope we don't need a
> Products.ZCatalog 2.14 release for that. Zope 2.13 can use it without
> five.globalrequest.
>
> See http://svn.zope.org/?rev=122892&view=rev
>
> Is that ok? Should I add an explicit extra in the setup.py of
> Products.ZCatalog?

That's ok. One minor nitpick: Instead of writing:

request = getattr(self, 'REQUEST', None)

I'd write:

request = aq_get(self, 'REQUEST', None)

with a module import of:

from Acquisition import aq_get

That way objects which have only an explicit AQ chain or only
__parent__ pointers will also work.

Hanno
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests