Fwd: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results

Sidnei da Silva sidnei at enfoldsystems.com
Wed Nov 15 15:16:33 UTC 2006

(Just so it's recorded on the list)

---------- Forwarded message ----------
From: Philipp von Weitershausen <philipp at weitershausen.de>
Date: Nov 15, 2006 1:15 PM
Subject: Re: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results
To: Sidnei da Silva <sidnei at enfoldsystems.com>

Sidnei da Silva wrote:
> On 11/15/06, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
>> Cool. I have two problems with this, though:
>> * the underscore clearly indicates the "privateness" of the _hold
>> method. In fact, _hold isn't part of the official Request API, I guess
>> (if there even is such a thing...)
>> * this doesn't seem to exist in Zope 3 (at least not in IRequest ;)).
> BEEEEP! Wrong answer! This is turned out to be public API but wasn't
> officialy named so for backward compatibility I guess. Someone should
> really have deprecated that in Zope 2 by adding an alias.
> In my local checkout of Zope 2.9, in lib/python/zope/publisher/base.py:
>    def hold(self, object):
>        'See IPublicationRequest'
>        self._held = self._held + (object,)

D'oh. It's in IPublicationRequest. Never mind then :).

>> Essentially, _hold() just adds properties to the request object. Why not
>> use attribute annotations? I think that makes for a bit cleaner approach
>> while still being flexible enough to make it work in both Zope 2 and 3...
> I don't see why since Zope 3 seems to have inherited hold().


+1 to request.hold().

http://worldcookery.com -- Professional Zope documentation and training

Sidnei da Silva
Enfold Systems                http://enfoldsystems.com
Fax +1 832 201 8856     Office +1 713 942 2377 Ext 214

More information about the Framework-Team mailing list