<br><br><div class="gmail_quote">On 19 September 2011 14:56, yuppie <span dir="ltr"><<a href="mailto:y.2011@wcm-solutions.de">y.2011@wcm-solutions.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi!<br>
<br>
<br>
Hanno Schlichting wrote:<br>
<div class="im">> On Mon, Sep 19, 2011 at 11:57 AM, yuppie<y.2011-E2EsyBC0hj3+aS/<a href="mailto:vkh9bjw@public.gmane.org">vkh9bjw@public.gmane.org</a>> wrote:<br>
>> Currently CMF trunk contains some hacks to work around the catalog brain<br>
>> issues. But I hope there is a better solution. Maybe the ICatalogBrain<br>
>> methods getURL, _unrestrictedGetObject and getObject should have a<br>
>> REQUEST argument that is used instead of self.REQUEST?<br>
>><br>
>> Any kind of feedback and help is welcome.<br>
><br>
> Mmh, why don't we just use zope.globalrequest in ZCatalog directly?<br>
> And create a new ZCatalog 2.14 release series with this. Then we don't<br>
> have to wait for Zope 4.0 to include it.<br>
<br>
</div>Using an explicit argument is always cleaner than using<br>
zope.globalrequest. And getObject() already has a (currently unused)<br>
REQUEST argument. And we might be able to provide a migration path for<br>
the API change: If we don't use registerToolInterface, we don't have to<br>
change getObject/getURL calls in places where we still use getToolByName.<br>
<br>
But with zope.globalrequest we can avoid modifying the API. So if it is<br>
fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might<br>
be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF?<br><br></blockquote><div><br></div><div>getURL() is an extremely common operation, and is often called in TALES expressions.</div><div><br></div><div>
-100 on making it take a mandatory request parameter when there are other solutions available.</div><div><br></div><div>Martin </div></div>