On Wed, Apr 05, 2006 at 11:23:40PM +0200, Stefan H. Holek wrote:
> Out of curiosity, you know that SimpleItem does not have a
> constructor? You just inherit the one from ExtensionClass.Base, which
> accepts everything and subsequently ignores it. So your item will
> have an empty id. This *m
Out of curiosity, you know that SimpleItem does not have a
constructor? You just inherit the one from ExtensionClass.Base, which
accepts everything and subsequently ignores it. So your item will
have an empty id. This *may* be what you want so your physical path
starts with '' instead of 'b
On Wed, Apr 05, 2006 at 11:48:31AM +0200, Stefan H. Holek wrote:
> Regarding your patch, why do you use lambda: () and not lambda: ('',)?
Because that would change the path of the wrapped object,
which is not a desirable side effect.
Here's the behavior with my patch:
>>> from Testing.makereques
On 4. Apr 2006, at 22:08, Paul Winkler wrote:
On Tue, Apr 04, 2006 at 08:09:05PM +0200, Stefan H. Holek wrote:
This looks fine to me because the world ends at parent. Your earlier
example wrapped an object that was in the middle of an acquisition
chain (IIRC),
no, I think you invented that :)
On Tue, Apr 04, 2006 at 08:09:05PM +0200, Stefan H. Holek wrote:
> This looks fine to me because the world ends at parent. Your earlier
> example wrapped an object that was in the middle of an acquisition
> chain (IIRC),
no, I think you invented that :)
> which I am not sure I like. You are
The one in ZopeTestCase.utils is also meant to play with startZServer
(same module). I agree that the one in Testing.makerequest could
probably gain ACTUAL_URL, and maybe even the request._steps hack to
make URL1 and friends available...
However, I have not seen these URL vars used anywhere
On 4. Apr 2006, at 16:53, Paul Winkler wrote:
Hmmm, but unit tests very often don't reflect "reality" -
deliberately!
Because "reality" is Too Much Stuff.
True enough.
Any other opinions on this? Do we really need to require an App at
the root any time we want to acquire REQUEST? That se
Stefan, do you have any insight into my first question?
I wrote:
> 1) there is a "makerequest" function in both Testing/makerequest.py
> and Testing/ZopeTestCase/utils.py. They are subtly different.
> Is there a deliberate reason for this? I notice that ... (snip)
> the one in makerequest.py lac
On Sat, Apr 01, 2006 at 01:07:35PM +0200, Stefan H. Holek wrote:
> I don't think makerequest is intended for wrapping anything but the
> root application object. Putting the RequestContainer on arbitrary
> objects doesn't feel right and certainly isn't how Zope does it, i.e.
> you get a test
I don't think makerequest is intended for wrapping anything but the
root application object. Putting the RequestContainer on arbitrary
objects doesn't feel right and certainly isn't how Zope does it, i.e.
you get a test fixture that doesn't reflect "reality".
NotABug/WontFix ;-)
Stefan
O
One small correction:
On Fri, Mar 31, 2006 at 12:31:55PM -0500, Paul Winkler wrote:
>... I notice that the makerequest
> in ZopeTestCase/utils.py lacks the recent fix for zope 3 views
No, it has that fix; I accidentally looked at it on
a 2.9.1 tarball rather than the trunk or 2.9 branch.
The res
Several things:
1) there is a "makerequest" function in both Testing/makerequest.py
and Testing/ZopeTestCase/utils.py. They are subtly different.
Is there a deliberate reason for this? I notice that the one
in utils.py lacks the recent fix for zope 3 views, and the one
in makerequest.py lacks an
12 matches
Mail list logo
