-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> Jens Vagelpohl wrote at 2006-10-11 12:03 -0400:
>> ...
>> I'm not sure this can be called a bug. It is true (and perfectly
>> normal) that rendering a filesystem page template will always call
>> the CPM. You're rendering
Dieter Maurer wrote:
Miles Waller wrote at 2006-10-11 16:34 +0100:
...
My question is, does this count as a bug?
I would say "yes"...
Please file a bug report to the CMF collector.
Done (incl. fix + tests): http://www.zope.org/Collectors/CMF/456
_
My question is, does this count as a bug?
I'm not sure this can be called a bug. It is true (and perfectly
normal) that rendering a filesystem page template will always call the
CPM. You're rendering both here. Since output_page_2 is rendered last
as it's calles from output_page_1 the rul
Tres Seaver wrote:
Note that the goal with unit tests is to use the *smallest possible
fixture*; using PortalTestCase when you could equally well use
RequestTest reduces the usefulness of the test:
- it runs slower (the "nibbled to death by ducks" effect, particularly
when re-running the
Tres Seaver wrote:
Jens Vagelpohl wrote:
I'm still -1 on merging the branch as it is and Stefan confirmed that
PortalTestCase should not be used directly: http://
mail.zope.org/pipermail/zope-cmf/2005-September/022932.html
Lets work on replacing the PortalTestCase in Testing.ZopeTestCase wi
Here's the result of my refactoring/rewriting for the tests in question:
http://svn.zope.org/CMF/branches/geoffd-cachingpolicymanager-branch/?
rev=38439&view=rev
Geoff, as the one with the most "domain knowledge" as far as the code
changes go, could you check the tests (and especially the co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
>> I'm still -1 on merging the branch as it is and Stefan confirmed that
>> PortalTestCase should not be used directly: http://
>> mail.zope.org/pipermail/zope-cmf/2005-September/022932.html
Lets work on replacing the PortalTes
On Fri, Sep 09, 2005 at 04:33:48PM +0100, Jens Vagelpohl wrote:
| >I'm still -1 on merging the branch as it is and Stefan confirmed
| >that PortalTestCase should not be used directly: http://
| >mail.zope.org/pipermail/zope-cmf/2005-September/022932.html
|
| How about a compromise: I'll spend a
On 9 Sep 2005, at 15:10, yuppie wrote:
Geoff Davis wrote:
On Fri, 09 Sep 2005 11:33:53 +0200, yuppie wrote:
Are you aware of the fact that test_Template304Handling.py
depends on PortalTestCase? Do you plan to change that before
merging your branch?
Yes, I am aware of that fact. No,
On 9 Sep 2005, at 16:48, Tres Seaver wrote:
Note that the goal with unit tests is to use the *smallest possible
fixture*; using PortalTestCase when you could equally well use
RequestTest reduces the usefulness of the test:
- it runs slower (the "nibbled to death by ducks" effect,
particular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent Guillaume wrote:
> How about just moving PortalTestCase to CMFCore/tests/whatever ?
CMFCore/tests/base/testcase.py would seem appropriate, with the concrete
version that actually instantiates a portal in
CMFDefault/tests/ ;)
Note that the goa
On Fri, 2005-09-09 at 16:10 +0200, yuppie wrote:
> I'm still -1 on merging the branch as it is and Stefan confirmed that
> PortalTestCase should not be used directly:
> http://mail.zope.org/pipermail/zope-cmf/2005-September/022932.html
Yes, Stefan and I are saying the same thing: the Right Way t
Geoff Davis wrote:
On Fri, 09 Sep 2005 11:33:53 +0200, yuppie wrote:
Are you aware of the fact that test_Template304Handling.py depends on
PortalTestCase? Do you plan to change that before merging your branch?
Yes, I am aware of that fact. No, I am not planning to change it -- it
works jus
> Hi Stefan!
>
>
> Stefan H. Holek wrote:
>> Well, you are supposed to use a subclass anyway, and in that subclass
>> you can fix everything, even _refreshSkinData.
>
> Sure there are ways to work around the problems. But nevertheless Zope
> should not contain code that requires knowledge about th
On Fri, 09 Sep 2005 11:33:53 +0200, yuppie wrote:
>> Perhaps I wasn't clear earlier when I said that I thought we should ship
>> our own CMFDefaultTestCase with the CMF? If I am understanding you
>> correctly, shipping a CMF-specific CMFDefaultTestCase should address your
>> dependency concerns.
yuppie wrote:
- Even with your workaround the tests are failing if run together with
CMFCalendar tests. Looks like the skin changes in
CalendarRequestTests.setUp are not cleaned up correctly.
Just checked in a fix for this. (1.5 branch and trunk)
Cheers, Yuppie
__
How about just moving PortalTestCase to CMFCore/tests/whatever ?
Florent
Stefan H. Holek wrote:
Well, you are supposed to use a subclass anyway, and in that subclass
you can fix everything, even _refreshSkinData. Maybe I should make
PortalTestCase truly abstract to emphasize the point.
Not
Hi Stefan!
Stefan H. Holek wrote:
Well, you are supposed to use a subclass anyway, and in that subclass
you can fix everything, even _refreshSkinData.
Sure there are ways to work around the problems. But nevertheless Zope
should not contain code that requires knowledge about the CMF.
Mayb
Well, you are supposed to use a subclass anyway, and in that subclass
you can fix everything, even _refreshSkinData. Maybe I should make
PortalTestCase truly abstract to emphasize the point.
NotImplementedError anyone? :-)
Stefan
On 9. Sep 2005, at 11:54, yuppie wrote:
That's great, but
Hi Stefan!
Stefan H. Holek wrote:
PortalTestCase is actually only intended as a base class for
CMFTestCase/PloneTestCase/CPSTestCase/whatever, not for direct use. It
provides some default behavior, because, for example, the requirement
to refresh the skin cache is pretty hard to figure out
Hi Geoff!
Geoff Davis wrote:
On Thu, 08 Sep 2005 19:24:51 +0200, yuppie wrote:
Knock! Knock! Anybody there?
I told you twice that I'm concerned about using PortalTestCase:
http://mail.zope.org/pipermail/zope-cmf/2005-September/022891.html
Would be nice to get some feedback. Obviously you do
Well, actually it is not correct ;-). PortalTestCase does *not*
provide a portal object but expects subclasses to take care of that
part of the fixture.
Stefan
On 9. Sep 2005, at 10:34, Stefan H. Holek wrote:
This is correct for the default configuration.
--
Anything that happens, happe
PortalTestCase is actually only intended as a base class for
CMFTestCase/PloneTestCase/CPSTestCase/whatever, not for direct use.
It provides some default behavior, because, for example, the
requirement to refresh the skin cache is pretty hard to figure out.
The ZopeTestCase philosophy is ab
This is correct for the default configuration. I deemed CMF site
creation fast enough at that time. In PloneTestCase, for example, we
instantiate a single portal at import time and reuse it for every
test. In the end it is a simple matter of overriding getPortal (which
is a hook that exists
Dieter Maurer wrote:
> Someone making occational changes may not be interested
> to be informed about all the modifications going on.
+1.
-PW
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See htt
Sidnei da Silva wrote:
| The z3interfaces tests are based on the assumption that Five is
| available if zope.interface is available. Five creates IActionInfo
| dynamically on startup.
|
| That's obviously not true in your setup. Looking again at these tests it
| would be more robust to include
On Thu, 08 Sep 2005 19:24:51 +0200, yuppie wrote:
> Knock! Knock! Anybody there?
>
> I told you twice that I'm concerned about using PortalTestCase:
> http://mail.zope.org/pipermail/zope-cmf/2005-September/022891.html
>
> Would be nice to get some feedback. Obviously you don't share those
> con
| The z3interfaces tests are based on the assumption that Five is
| available if zope.interface is available. Five creates IActionInfo
| dynamically on startup.
|
| That's obviously not true in your setup. Looking again at these tests it
| would be more robust to include the interface imports i
Jens Vagelpohl wrote at 2005-9-8 11:41 +0100:
>
>On 8 Sep 2005, at 11:08, yuppie wrote:
> ...
>Geoff, can you double-
>check that the email address you have in your zope.org membership is
>correct and then subscribe to the cmf-checkins list? That should make
>any further check-in messages appe
Hi Geoff!
Geoff Davis wrote:
On Thu, 08 Sep 2005 12:08:23 +0200, yuppie wrote:
- Tests are easier to find and maintain if they are located in
test_.py. Most CMF tests follow that pattern.
Yes, I put the tests relating to new CachingPolicyManager functionality
into test_CachingPolicyManager
On 8 Sep 2005, at 16:48, Geoff Davis wrote:
bin/zopectl test --dir Products/CMFCore/tests
I get a bunch of errors like the following:
==
ERROR: test_z3interfaces
(CMFCore.tests.test_ActionInformation.ActionInfoTests)
--
On Thu, 08 Sep 2005 12:08:23 +0200, yuppie wrote:
> - Please make sure your checkins show up on the CMF-checkins list. Don't
> know if Tres can fix that for you or if you've got to register for that
> list.
Ok, I will look into it.
> - Please don't forget to set svn:eol-style and svn:keywords
whit wrote:
Agreed. Nevertheless we should focus on lowering the barrier of entry
for new CMF contributors. People used to write tests for Zope or Plone
will have less trouble if they can use ZopeTestCase. And ZopeTestCase
tests are definitely better than no tests at all.
and it's include
On 8 Sep 2005, at 12:00, yuppie wrote:
PS Those of you who raised concerns about ZopeTestCase causing
test
problems in Zope 2.7 might want to take a look at why
test_z3interfaces is
broken when you run the tests with zopectl test.
1.) Why "those of you who raised concerns about ZopeTest
Jens Vagelpohl wrote:
On 8 Sep 2005, at 11:08, yuppie wrote:
PS Those of you who raised concerns about ZopeTestCase causing test
problems in Zope 2.7 might want to take a look at why
test_z3interfaces is
broken when you run the tests with zopectl test.
1.) Why "those of you who raised co
On 8 Sep 2005, at 11:08, yuppie wrote:
- Please make sure your checkins show up on the CMF-checkins list.
Don't know if Tres can fix that for you or if you've got to
register for that list.
I was wondering why I did not get any mail... Geoff, can you double-
check that the email address y
Hi Geoff!
Geoff Davis wrote:
I have checked my CachingPolicyManager improvements into the
geoffd-cachingpolicymanager-branch. Enjoy!
Great!
Some feedback regard formal aspects:
- Please make sure your checkins show up on the CMF-checkins list. Don't
know if Tres can fix that for you or if
Agreed. Nevertheless we should focus on lowering the barrier of entry
for new CMF contributors. People used to write tests for Zope or Plone
will have less trouble if they can use ZopeTestCase. And ZopeTestCase
tests are definitely better than no tests at all.
and it's included as part of
Geoff Davis wrote:
RAMCacheManager has no good way to purge stale content.
ZCacheable_invalidate()?
(granted, in practice it's currently broken for skins...
http://www.zope.org/Collectors/CMF/343 )
It's not just that RAMCacheManager has bugs. ZCacheable_invalidate, when
called, invalidates
Florent wrote:
> There's also some text in the online help about caching complete web
> pages being a bad idea.
And in the docstring of the source too.
-PW
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cm
On 6 Sep 2005, at 20:05, Dieter Maurer wrote:
Florent Guillaume wrote at 2005-9-6 15:30 +0200:
...
Of course if you directly serve content objects from the cache, which
is explicitely unsupported and not recommended...
Where did you find this information ("*explicitely* unsupported").
When
Florent Guillaume wrote at 2005-9-6 15:30 +0200:
> ...
>Of course if you directly serve content objects from the cache, which
>is explicitely unsupported and not recommended...
Where did you find this information ("*explicitely* unsupported").
--
Dieter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Winkler wrote:
>>On 6 Sep 2005, at 15:24, Alexander Limi wrote:
>>
>>>On Tue, 06 Sep 2005 12:21:07 +0200, Florent Guillaume
>>><[EMAIL PROTECTED]> wrote:
>>>
Alexander Limi wrote:
> And the biggest etc: RAMCache does not know how to h
> On 6 Sep 2005, at 15:24, Alexander Limi wrote:
>> On Tue, 06 Sep 2005 12:21:07 +0200, Florent Guillaume
>> <[EMAIL PROTECTED]> wrote:
>>> Alexander Limi wrote:
And the biggest etc: RAMCache does not know how to handle
anything but 7-bit ASCII data.
>>>
>>> What? There's no such l
On 6 Sep 2005, at 15:24, Alexander Limi wrote:
On Tue, 06 Sep 2005 12:21:07 +0200, Florent Guillaume
<[EMAIL PROTECTED]> wrote:
Alexander Limi wrote:
And the biggest etc: RAMCache does not know how to handle
anything but 7-bit ASCII data.
What? There's no such limitation. RAMCacheManage
Alexander Limi wrote:
On Tue, 06 Sep 2005 06:18:30 +0200, Geoff Davis <[EMAIL PROTECTED]> wrote:
RAMCacheManager has no good way to purge stale content. RAMCacheManager
is limited to RAM for its cache. Etc.
And the biggest etc: RAMCache does not know how to handle anything but
7-bit ASCII
Dieter Maurer wrote:
yuppie wrote at 2005-9-5 14:06 +0200:
...
PortalTestCase is in the wrong layer. It makes assumptions about the way
CMF works. Changes to the CMF might break PortalTestCase and create a
dependency on a new Zope release. (We saw that problem already with the
_refreshSkinDa
On Monday 05 September 2005 09:27 am, Geoff Davis wrote:
> On Mon, 05 Sep 2005 18:15:41 +0200, Florent Guillaume wrote:
> >>> If an FSPageTemplate is associated with a Caching Policy and that
> >>> Caching Policy has 304s explicitly enabled, a series of checks take
> >>> place. If there is an If-M
yuppie wrote at 2005-9-5 14:06 +0200:
> ...
>PortalTestCase is in the wrong layer. It makes assumptions about the way
>CMF works. Changes to the CMF might break PortalTestCase and create a
>dependency on a new Zope release. (We saw that problem already with the
>_refreshSkinData changes in CMF 1
On Mon, 05 Sep 2005 14:06:50 +0200, yuppie wrote:
> Agreed. Nevertheless we should focus on lowering the barrier of entry
> for new CMF contributors. People used to write tests for Zope or Plone
> will have less trouble if they can use ZopeTestCase. And ZopeTestCase
> tests are definitely better
On Mon, 05 Sep 2005 18:15:41 +0200, Florent Guillaume wrote:
>>> If an FSPageTemplate is associated with a Caching Policy and that Caching
>>> Policy has 304s explicitly enabled, a series of checks take place. If
>>> there is an If-Modified-Since header, the server checks the modification
>>> tim
Hm I fucked the Cc field, resending.
Florent Guillaume wrote:
Geoff Davis wrote:
3) FSPageTemplates have the option to return a status 304 + no content
when a conditional GET is sent. This is a potential significant win for
sites.
How it works: When a client has an expired page in its local c
yuppie wrote:
Florent Guillaume wrote:
[..]
However this kind of default fixture actually is quite heavy, and
makes you write tests that are hardly "unit" anymore. They are still
good integration tests, but I've found that using PortalTestCase or
something like that is often extremely costly
Florent Guillaume wrote:
Geoff Davis wrote:
I'm sure I won't do Stefan's work full justice (feel free to chime in,
Stefan!). The most important thing in my mind that ZopeTestCase does is
to make it simpler to set up your test fixture. ZopeTestCase creates a
new folder to work in, adds a user
On 5 Sep 2005, at 11:45, Florent Guillaume wrote:
However this kind of default fixture actually is quite heavy, and
makes you write tests that are hardly "unit" anymore. They are
still good integration tests, but I've found that using
PortalTestCase or something like that is often extremely
Geoff Davis wrote:
I'm sure I won't do Stefan's work full justice (feel free to chime in,
Stefan!). The most important thing in my mind that ZopeTestCase does is
to make it simpler to set up your test fixture. ZopeTestCase creates a
new folder to work in, adds a user folder, and creates a user.
On Sat, 03 Sep 2005 22:16:14 +0200, Jens Vagelpohl <[EMAIL PROTECTED]>
wrote:
Part of Zope version 2.8 and up, that's the problem. If you were to run
a clean Zope 2.7.x, downloaded a release version of CMF 1.5.x and ran
the unit tests, would you expect to see any breakage? I wouldn't want t
On Fri, 02 Sep 2005 18:42:56 -0400, Tres Seaver wrote:
> I'm not quite wure what ZTC buys us for unit testing; is it primarily
> used to get the environment right for a functional test? Is it needed
> when running the tests via 'bin/zopectl test' in an instance home?
I'm sure I won't do Stefan'
On 2 Sep 2005, at 23:49, Geoff Davis wrote:
On Fri, 02 Sep 2005 23:08:37 +0100, Jens Vagelpohl wrote:
IMHO there is at least one problematic item (well, it's not for the
trunk, but for the 1.5/1.4 branches), which is the dependency on
ZopeTestCase. The way the code works right now you immedia
On Fri, 02 Sep 2005 23:08:37 +0100, Jens Vagelpohl wrote:
> IMHO there is at least one problematic item (well, it's not for the
> trunk, but for the 1.5/1.4 branches), which is the dependency on
> ZopeTestCase. The way the code works right now you immediately
> prevent any tests from running
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
>> I have written unit tests for all the new functionality including what I
>> believe to be the first CMFCore test suite to use ZopeTestCase.
>> ZopeTestCase provides a lot of useful functionality, including
>> functional tests
61 matches
Mail list logo
