[Zope-Checkins] SVN: Zope/trunk/src/Zope2/App/startup.py Merged c101854 from 2.12 branch
Log message for revision 101855:
Merged c101854 from 2.12 branch
Changed:
U Zope/trunk/src/Zope2/App/startup.py
-=-
Modified: Zope/trunk/src/Zope2/App/startup.py
===
--- Zope/trunk/src/Zope2/App/startup.py 2009-07-13 15:14:03 UTC (rev 101854)
+++ Zope/trunk/src/Zope2/App/startup.py 2009-07-13 15:15:44 UTC (rev 101855)
@@ -167,30 +167,25 @@
def __call__(self, published, REQUEST, t, v, traceback):
try:
-if isinstance(t, StringType):
-if t.lower() in ('unauthorized', 'redirect'):
-raise
-else:
-if (t is SystemExit or
-issubclass(t, Redirect) or issubclass(t, Unauthorized)):
-raise
+if t is SystemExit or issubclass(t, Redirect):
+raise
+if issubclass(t, ConflictError):
+self.logConflicts(v, REQUEST)
+raise ZPublisher.Retry(t, v, traceback)
+
+if t is ZPublisher.Retry:
+try:
+v.reraise()
+except:
+# we catch the re-raised exception so that it gets
+# stored in the error log and gets rendered with
+# standard_error_message
+t, v, traceback = sys.exc_info()
if issubclass(t, ConflictError):
-self.logConflicts(v, REQUEST)
-raise ZPublisher.Retry(t, v, traceback)
+# ouch, a user saw this conflict error :-(
+self.unresolved_conflict_errors += 1
-if t is ZPublisher.Retry:
-try:
-v.reraise()
-except:
-# we catch the re-raised exception so that it gets
-# stored in the error log and gets rendered with
-# standard_error_message
-t, v, traceback = sys.exc_info()
-if issubclass(t, ConflictError):
-# ouch, a user saw this conflict error :-(
-self.unresolved_conflict_errors += 1
-
try:
log = aq_acquire(published, '__error_log__', containment=1)
except AttributeError:
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/ Removed handling of string exceptions from ZPublisherExceptionHook and reverted the addition of Unauthorized exceptions to be always re-raised. This broke the
Log message for revision 101854:
Removed handling of string exceptions from ZPublisherExceptionHook and
reverted the addition of Unauthorized exceptions to be always re-raised. This
broke the tests.
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U Zope/branches/2.12/src/Zope2/App/startup.py
-=-
Modified: Zope/branches/2.12/doc/CHANGES.rst
===
--- Zope/branches/2.12/doc/CHANGES.rst 2009-07-13 15:13:07 UTC (rev 101853)
+++ Zope/branches/2.12/doc/CHANGES.rst 2009-07-13 15:14:03 UTC (rev 101854)
@@ -39,7 +39,7 @@
- ObjectManagerNameChooser now also works with BTreeFolder2.
-- Correctly handle unauthorized exceptions in the ZPublisherExceptionHook.
+- Correctly handle exceptions in the ZPublisherExceptionHook.
Zope 2.12.0 b2 (2009/05/27)
---
Modified: Zope/branches/2.12/src/Zope2/App/startup.py
===
--- Zope/branches/2.12/src/Zope2/App/startup.py 2009-07-13 15:13:07 UTC (rev
101853)
+++ Zope/branches/2.12/src/Zope2/App/startup.py 2009-07-13 15:14:03 UTC (rev
101854)
@@ -167,30 +167,25 @@
def __call__(self, published, REQUEST, t, v, traceback):
try:
-if isinstance(t, StringType):
-if t.lower() in ('unauthorized', 'redirect'):
-raise
-else:
-if (t is SystemExit or
-issubclass(t, Redirect) or issubclass(t, Unauthorized)):
-raise
+if t is SystemExit or issubclass(t, Redirect):
+raise
+if issubclass(t, ConflictError):
+self.logConflicts(v, REQUEST)
+raise ZPublisher.Retry(t, v, traceback)
+
+if t is ZPublisher.Retry:
+try:
+v.reraise()
+except:
+# we catch the re-raised exception so that it gets
+# stored in the error log and gets rendered with
+# standard_error_message
+t, v, traceback = sys.exc_info()
if issubclass(t, ConflictError):
-self.logConflicts(v, REQUEST)
-raise ZPublisher.Retry(t, v, traceback)
+# ouch, a user saw this conflict error :-(
+self.unresolved_conflict_errors += 1
-if t is ZPublisher.Retry:
-try:
-v.reraise()
-except:
-# we catch the re-raised exception so that it gets
-# stored in the error log and gets rendered with
-# standard_error_message
-t, v, traceback = sys.exc_info()
-if issubclass(t, ConflictError):
-# ouch, a user saw this conflict error :-(
-self.unresolved_conflict_errors += 1
-
try:
log = aq_acquire(published, '__error_log__', containment=1)
except AttributeError:
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Updated to new versions of zope.app.component, zope.app.zcmlfiles and zope.testing
Log message for revision 101856: Updated to new versions of zope.app.component, zope.app.zcmlfiles and zope.testing Changed: U Zope/trunk/doc/CHANGES.rst U Zope/trunk/versions.cfg -=- Modified: Zope/trunk/doc/CHANGES.rst === --- Zope/trunk/doc/CHANGES.rst 2009-07-13 15:15:44 UTC (rev 101855) +++ Zope/trunk/doc/CHANGES.rst 2009-07-13 15:45:41 UTC (rev 101856) @@ -27,19 +27,20 @@ - zc.buildout = 1.3.0 - zope.app.appsetup = 3.12.0 - zope.app.cache = 3.6.0 + - zope.app.component = 3.8.3 - zope.app.pagetemplate = 3.7.1 - zope.app.publication = 3.8.1 - zope.app.publisher = 3.8.3 - zope.app.testing = 3.7.0 - zope.app.wsgi = 3.6.0 - - zope.app.zcmlfiles = 3.5.5 + - zope.app.zcmlfiles = 3.6.0 - zope.contenttype = 3.4.2 - zope.dublincore = 3.4.3 - zope.i18nmessageid = 3.5.0 - zope.index = 3.5.2 - zope.interface = 3.5.2 - zope.server = 3.6.0 - - zope.testing = 3.7.5 + - zope.testing = 3.7.6 - zope.traversing = 3.7.1 - ZConfig = 2.7.1 - ZODB = 3.9.0b2 Modified: Zope/trunk/versions.cfg === --- Zope/trunk/versions.cfg 2009-07-13 15:15:44 UTC (rev 101855) +++ Zope/trunk/versions.cfg 2009-07-13 15:45:41 UTC (rev 101856) @@ -33,7 +33,7 @@ zope.app.basicskin = 3.4.0 zope.app.broken = 3.5.0 zope.app.cache = 3.6.0 -zope.app.component = 3.8.2 +zope.app.component = 3.8.3 zope.app.container = 3.8.0 zope.app.content = 3.4.0 zope.app.debug = 3.4.1 @@ -60,7 +60,7 @@ zope.app.session = 3.6.0 zope.app.testing = 3.7.0 zope.app.wsgi = 3.6.0 -zope.app.zcmlfiles = 3.5.5 +zope.app.zcmlfiles = 3.6.0 zope.app.zopeappgenerations = 3.5.0 zope.app.zptpage = 3.5.0 zope.authentication = 3.7.0 @@ -119,7 +119,7 @@ zope.tal = 3.5.1 zope.tales = 3.4.0 zope.testbrowser = 3.6.0a2 -zope.testing = 3.7.5 +zope.testing = 3.7.6 zope.thread = 3.4 zope.traversing = 3.7.1 zope.viewlet = 3.5.0 ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/ Added support to indexing datetime values to the PluginIndexes DateRangeIndex. The DateIndex already had this feature.
Log message for revision 101857:
Added support to indexing datetime values to the PluginIndexes
DateRangeIndex. The DateIndex already had this feature.
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
U
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
-=-
Modified: Zope/branches/2.12/doc/CHANGES.rst
===
--- Zope/branches/2.12/doc/CHANGES.rst 2009-07-13 15:45:41 UTC (rev 101856)
+++ Zope/branches/2.12/doc/CHANGES.rst 2009-07-13 16:25:34 UTC (rev 101857)
@@ -16,6 +16,9 @@
* ZODB 3.9.0b2
+- Added support to indexing datetime values to the PluginIndexes
+ DateRangeIndex. The DateIndex already had this feature.
+
Restructuring
+
Modified:
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
===
---
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
2009-07-13 15:45:41 UTC (rev 101856)
+++
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
2009-07-13 16:25:34 UTC (rev 101857)
@@ -16,6 +16,7 @@
import os
+from datetime import datetime
from AccessControl.Permissions import manage_zcatalog_indexes
from AccessControl.Permissions import view
@@ -385,10 +386,10 @@
def _convertDateTime( self, value ):
if value is None:
return value
-if isinstance(value, str):
+if isinstance(value, (str, datetime)):
dt_obj = DateTime( value )
value = dt_obj.millis() / 1000 / 60 # flatten to minutes
-if isinstance(value, DateTime):
+elif isinstance(value, DateTime):
value = value.millis() / 1000 / 60 # flatten to minutes
result = int( value )
if isinstance(result, long): # this won't work (Python 2.3)
Modified:
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
===
---
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
2009-07-13 15:45:41 UTC (rev 101856)
+++
Zope/branches/2.12/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
2009-07-13 16:25:34 UTC (rev 101857)
@@ -141,7 +141,36 @@
bad = Dummy( 'bad', long(sys.maxint) + 1, long(sys.maxint) + 1 )
work.index_object( 0, bad )
+def test_datetime(self):
+from datetime import datetime
+before = datetime(2009, 7, 11, 0, 0)
+start = datetime(2009, 7, 13, 5, 15)
+between = datetime(2009, 7, 13, 5, 45)
+stop = datetime(2009, 7, 13, 6, 30)
+after = datetime(2009, 7, 14, 0, 0)
+dummy = Dummy('test', start, stop)
+work = DateRangeIndex( 'work', 'start', 'stop' )
+work.index_object(0, dummy)
+
+assert work.getEntryForObject(0) == (20790915, 20790990)
+
+results, used = work._apply_index( { 'work' : before } )
+assert len(results) == 0
+
+results, used = work._apply_index( { 'work' : start } )
+assert len(results) == 1
+
+results, used = work._apply_index( { 'work' : between } )
+assert len(results) == 1
+
+results, used = work._apply_index( { 'work' : stop } )
+assert len(results) == 1
+
+results, used = work._apply_index( { 'work' : after } )
+assert len(results) == 0
+
+
def test_suite():
suite = unittest.TestSuite()
suite.addTest( unittest.makeSuite( DRI_Tests ) )
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/ Merged c101857 from 2.12 branch
Log message for revision 101858:
Merged c101857 from 2.12 branch
Changed:
U Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
U
Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
-=-
Modified: Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
===
--- Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
2009-07-13 16:25:34 UTC (rev 101857)
+++ Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/DateRangeIndex.py
2009-07-13 16:26:41 UTC (rev 101858)
@@ -16,6 +16,7 @@
import os
+from datetime import datetime
from AccessControl.Permissions import manage_zcatalog_indexes
from AccessControl.Permissions import view
@@ -385,10 +386,10 @@
def _convertDateTime( self, value ):
if value is None:
return value
-if isinstance(value, str):
+if isinstance(value, (str, datetime)):
dt_obj = DateTime( value )
value = dt_obj.millis() / 1000 / 60 # flatten to minutes
-if isinstance(value, DateTime):
+elif isinstance(value, DateTime):
value = value.millis() / 1000 / 60 # flatten to minutes
result = int( value )
if isinstance(result, long): # this won't work (Python 2.3)
Modified:
Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
===
---
Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
2009-07-13 16:25:34 UTC (rev 101857)
+++
Zope/trunk/src/Products/PluginIndexes/DateRangeIndex/tests/test_DateRangeIndex.py
2009-07-13 16:26:41 UTC (rev 101858)
@@ -141,7 +141,36 @@
bad = Dummy( 'bad', long(sys.maxint) + 1, long(sys.maxint) + 1 )
work.index_object( 0, bad )
+def test_datetime(self):
+from datetime import datetime
+before = datetime(2009, 7, 11, 0, 0)
+start = datetime(2009, 7, 13, 5, 15)
+between = datetime(2009, 7, 13, 5, 45)
+stop = datetime(2009, 7, 13, 6, 30)
+after = datetime(2009, 7, 14, 0, 0)
+dummy = Dummy('test', start, stop)
+work = DateRangeIndex( 'work', 'start', 'stop' )
+work.index_object(0, dummy)
+
+assert work.getEntryForObject(0) == (20790915, 20790990)
+
+results, used = work._apply_index( { 'work' : before } )
+assert len(results) == 0
+
+results, used = work._apply_index( { 'work' : start } )
+assert len(results) == 1
+
+results, used = work._apply_index( { 'work' : between } )
+assert len(results) == 1
+
+results, used = work._apply_index( { 'work' : stop } )
+assert len(results) == 1
+
+results, used = work._apply_index( { 'work' : after } )
+assert len(results) == 0
+
+
def test_suite():
suite = unittest.TestSuite()
suite.addTest( unittest.makeSuite( DRI_Tests ) )
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/ Updated all packages to latest maintenance releases. Also updated ZConfig and pytz to latest features release.
Log message for revision 101863: Updated all packages to latest maintenance releases. Also updated ZConfig and pytz to latest features release. Changed: U Zope/branches/2.12/doc/CHANGES.rst U Zope/branches/2.12/versions.cfg -=- Modified: Zope/branches/2.12/doc/CHANGES.rst === --- Zope/branches/2.12/doc/CHANGES.rst 2009-07-13 16:43:27 UTC (rev 101862) +++ Zope/branches/2.12/doc/CHANGES.rst 2009-07-13 16:51:27 UTC (rev 101863) @@ -14,7 +14,19 @@ - Updated packages: - * ZODB 3.9.0b2 + - ZConfig = 2.7.1 + - ZODB = 3.9.0b2 + - pytz = 2009j + - zope.app.component = 3.8.3 + - zope.app.pagetemplate = 3.7.1 + - zope.app.publisher = 3.8.3 + - zope.app.zcmlfiles = 3.5.5 + - zope.contenttype = 3.4.2 + - zope.dublincore = 3.4.3 + - zope.index = 3.5.2 + - zope.interface = 3.5.2 + - zope.testing = 3.7.6 + - zope.traversing = 3.7.1 - Added support to indexing datetime values to the PluginIndexes DateRangeIndex. The DateIndex already had this feature. Modified: Zope/branches/2.12/versions.cfg === --- Zope/branches/2.12/versions.cfg 2009-07-13 16:43:27 UTC (rev 101862) +++ Zope/branches/2.12/versions.cfg 2009-07-13 16:51:27 UTC (rev 101863) @@ -12,16 +12,16 @@ # Zope Toolkit KGS ClientForm = 0.2.10 RestrictedPython = 3.5.1 -ZConfig = 2.6.1 +ZConfig = 2.7.1 ZODB3 = 3.9.0b2 docutils = 0.5 lxml = 2.2 mechanize = 0.1.11 python-gettext = 1.0 -pytz = 2009g +pytz = 2009j setuptools = 0.6c9 transaction = 1.0a1 -zc.buildout = 1.2.1 +zc.buildout = 1.3.0 zc.lockfile = 1.0.0 zc.recipe.egg = 1.2.2 zc.recipe.testrunner = 1.2.0 @@ -31,11 +31,12 @@ zope.app.apidoc = 3.6.2 zope.app.applicationcontrol = 3.5.0 zope.app.appsetup = 3.11 +zope.app.authentication = 3.6.0 zope.app.basicskin = 3.4.0 zope.app.broken = 3.5.0 zope.app.cache = 3.5.0 zope.app.catalog = 3.8.0 -zope.app.component = 3.8.2 +zope.app.component = 3.8.3 zope.app.container = 3.8.0 zope.app.content = 3.4.0 zope.app.dav = 3.5.0 @@ -54,11 +55,12 @@ zope.app.intid = 3.7.0 zope.app.locales = 3.5.1 zope.app.localpermission = 3.7.0 -zope.app.pagetemplate = 3.7.0 +zope.app.pagetemplate = 3.7.1 zope.app.principalannotation = 3.6.1 zope.app.publication = 3.7.0 -zope.app.publisher = 3.8.1 +zope.app.publisher = 3.8.3 zope.app.renderer = 3.5.0 +zope.app.rotterdam = 3.5.0 zope.app.schema = 3.5.0 zope.app.security = 3.7.0 zope.app.securitypolicy = 3.5.1 @@ -69,7 +71,7 @@ zope.app.undo = 3.5.0 zope.app.wsgi = 3.5.2 zope.app.zapi = 3.4.0 -zope.app.zcmlfiles = 3.5.3 +zope.app.zcmlfiles = 3.5.5 zope.app.zopeappgenerations = 3.5.0 zope.app.zptpage = 3.5.0 zope.authentication = 3.7.0 @@ -82,7 +84,7 @@ zope.configuration = 3.6.0 zope.container = 3.8.2 zope.contentprovider = 3.5.0 -zope.contenttype = 3.4.1 +zope.contenttype = 3.4.2 zope.copy = 3.5.0 zope.copypastemove = 3.5.1 zope.datetime = 3.4.0 @@ -91,7 +93,7 @@ zope.deprecation = 3.4.0 zope.documenttemplate = 3.4.2 zope.dottedname = 3.4.5 -zope.dublincore = 3.4.2 +zope.dublincore = 3.4.3 zope.error = 3.6.0 zope.event = 3.4.1 zope.exceptions = 3.5.2 @@ -100,13 +102,14 @@ zope.hookable = 3.4.1 zope.i18n = 3.7.0 zope.i18nmessageid = 3.4.3 -zope.index = 3.5.1 -zope.interface = 3.5.1 +zope.index = 3.5.2 +zope.interface = 3.5.2 zope.intid = 3.7.0 zope.keyreference = 3.6.1 zope.lifecycleevent = 3.5.2 zope.location = 3.5.4 zope.minmax = 1.1.0 +zope.modulealias = 3.4.0 zope.password = 3.5.1 zope.pagetemplate = 3.5.0 zope.principalannotation = 3.6.0 @@ -127,6 +130,7 @@ zope.tal = 3.5.1 zope.tales = 3.4.0 zope.testbrowser = 3.6.0a2 -zope.testing = 3.7.4 -zope.traversing = 3.7.0 +zope.testing = 3.7.6 +zope.thread = 3.4 +zope.traversing = 3.7.1 zope.viewlet = 3.5.0 ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/doc/CHANGES.rst Don't mention package updates, which have already happened in Zope 2.12
Log message for revision 101864: Don't mention package updates, which have already happened in Zope 2.12 Changed: U Zope/trunk/doc/CHANGES.rst -=- Modified: Zope/trunk/doc/CHANGES.rst === --- Zope/trunk/doc/CHANGES.rst 2009-07-13 16:51:27 UTC (rev 101863) +++ Zope/trunk/doc/CHANGES.rst 2009-07-13 17:06:12 UTC (rev 101864) @@ -11,7 +11,7 @@ Restructuring + -- Centralize interfaces defined in Products.ZCTextIndex, leaving BBB +- Centralize interfaces defined in Products.ZCTextIndex, leaving BBB imports behind in old locations. - Integrated zLOG package back into this package. @@ -23,27 +23,14 @@ - Updated packages: - - pytz = 2009j - - zc.buildout = 1.3.0 - zope.app.appsetup = 3.12.0 - zope.app.cache = 3.6.0 - - zope.app.component = 3.8.3 - - zope.app.pagetemplate = 3.7.1 - zope.app.publication = 3.8.1 - - zope.app.publisher = 3.8.3 - zope.app.testing = 3.7.0 - zope.app.wsgi = 3.6.0 - zope.app.zcmlfiles = 3.6.0 - - zope.contenttype = 3.4.2 - - zope.dublincore = 3.4.3 - zope.i18nmessageid = 3.5.0 - - zope.index = 3.5.2 - - zope.interface = 3.5.2 - zope.server = 3.6.0 - - zope.testing = 3.7.6 - - zope.traversing = 3.7.1 - - ZConfig = 2.7.1 - - ZODB = 3.9.0b2 Bugs Fixed ++ ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] test setup layer sorting
zope/testing/testrunner/runner.py's order_by_bases() function orders layers by inheritance, basically. So if you've got a FunctionalTestLayer that inherits from some BasicTestLayer, the tests that use the basic test layer will be executed before the functional test layer ones. If there's no inheritance, the layers are sorted by name. Quite sane. Problem: I use grok. Which does some magic that probably throws off the code coverage reports. Quite some code appears untested, even though I *do* test it. The problem disappears if just import the python module first in some basic test before the grokking happened. I use z3c.testsetup: - My basic doctests end up on the zope.testing.testrunner.layer.UnitTests layer. - My functional doctests on the z3c.testsetup.functional.layer.DefaultZCMLLayer layer which inherits from zope.app.testing's ZCMLLayer. - zope.app.testing's ZCMLLayer does not inherit from anything, so also not from zope.testing's unittest layer. - 'zope' is alphabetically behind 'z3c.testsetup', so the functional layer is sorted in front of the basic unittest one. - So my grokked code appears untested. What's the best solution? Should zope.app.testing's ZCMLLayer inherit from zope.testing's UnitTests layer? Should z3c.testsetup do some inheriting of its own? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 09:27:54AM +, Reinout van Rees wrote: zope/testing/testrunner/runner.py's order_by_bases() function orders layers by inheritance, basically. So if you've got a FunctionalTestLayer that inherits from some BasicTestLayer, the tests that use the basic test layer will be executed before the functional test layer ones. If there's no inheritance, the layers are sorted by name. Quite sane. Problem: I use grok. Which does some magic that probably throws off the code coverage reports. Quite some code appears untested, even though I *do* test it. The problem disappears if just import the python module first in some basic test before the grokking happened. I use z3c.testsetup: - My basic doctests end up on the zope.testing.testrunner.layer.UnitTests layer. - My functional doctests on the z3c.testsetup.functional.layer.DefaultZCMLLayer layer which inherits from zope.app.testing's ZCMLLayer. - zope.app.testing's ZCMLLayer does not inherit from anything, so also not from zope.testing's unittest layer. - 'zope' is alphabetically behind 'z3c.testsetup', so the functional layer is sorted in front of the basic unittest one. - So my grokked code appears untested. What's the best solution? Whatever grok does that interferes with coverage should be fixed. Should zope.app.testing's ZCMLLayer inherit from zope.testing's UnitTests layer? Personally I would much prefer for the unit test layer to be sorted first. It is already treated specially by zope.testing; I see no harm in hardcoding its sort order. Should z3c.testsetup do some inheriting of its own? That to me sounds like the wrong place to fix this. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: data manager forPersistentDict/PersistentMapping
Am 12.07.2009 um 01:46 schrieb Roger Ineichen: Hi Michael Betreff: [Zope-dev] z3c.form: data manager forPersistentDict/PersistentMapping Hello, z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one: 1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.) I think this is the right solution I think so, too, but I was not sure. because there are many places in zope which do not work if a PeristentDict or PeristentList is given instead of a simple dict or list type. I'm not sure but I guess not even the zope.schema validation implementation does this part correct for list or dict fields. This is another problem. z3c.form.datamanager.DictionaryField sets the value directly on the dict, so I'd like to use a PersistentMapping instead of a dict to get the persistency stuff for free. I use the PersistentMapping to store the schema values, as I need to keep them in the session. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: data manager for PersistentDict/PersistentMapping
Am 11.07.2009 um 17:43 schrieb Michael Howitz: Hello, z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one: 1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.) 2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?) Replying to myself, as I saw on the z3c.form trunk that DictionaryField already allows providers of zope.interface.common.mapping.IMapping additionally to dict instances as the storage object. The existing solution uses the second of my possibilities, but this is not the one which I'd like to prefer, as it does not work with PersistentMapping out of the box. The idea behind this change on the trunk seems to be: to allow SessionPkgData as storage. I currently do not use it directly but use a PersistentMapping inside SessionPkgData. But maybe this is a sufficient solution for now. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Creating new five.* package
We've started a new package, five.hashedresource, that is supposed to integrate z3c.hashedresource into Zope2. Just to make sure not to step on someone's toes: is it OK to just create such a package in that namespace? -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Creating new five.* package
On Mon, Jul 13, 2009 at 1:28 PM, Thomas Lotzetho...@thomas-lotze.de wrote: We've started a new package, five.hashedresource, that is supposed to integrate z3c.hashedresource into Zope2. Just to make sure not to step on someone's toes: is it OK to just create such a package in that namespace? +1, the namespace is pretty clear for anything that integrates newer zope.* stuff into Zope2. Even though, the original 2+3 = 5 equation doesn't work anymore with 2+ZTK = ?, I think the name is well established. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On 2009-07-13, Marius Gedminas mar...@gedmin.as wrote: Whatever grok does that interferes with coverage should be fixed. I did some more debugging. In the end it boils down to this: With z3c.testsetup, you can specify a zcml file at the top of your test file. z3c.testsetup creates a ZCMLLayer with that zcml file. I my test files, I had two separate zcml files (one registered a bit more than the other). So I ended up with two separate ZCMLLayer subclasses. And both did some grokking. So apparently the teardown of a ZCMLLayer subclass when going from one to the next isn't that clean. There *is* a warning in zope.testing that teardown isn't fully supported. Personally, I'm not sure where the exact problem is. Grok does decorator-like wrapping (should not throw off the coverage testing) and plain component architecture registration (should not throw off the coverage testing either). Tearing down a component architecture layer? Code coverage problems don't seem too common. Probably an interaction between two problems. How I solved it: just use one zcml layer in z3c.testsetup and do some extra grokking in the test itself instead of in the second zcml file. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 5:55 AM, Marius Gedminasmar...@gedmin.as wrote: Personally I would much prefer for the unit test layer to be sorted first. It is already treated specially by zope.testing; I see no harm in hardcoding its sort order. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: data manager for PersistentDict/PersistentMapping
On Saturday 11 July 2009, Michael Howitz wrote: z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one: 1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.) 2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?) I looked at this recently and the reason is that for containers we did not usually want the dictionary field data manager, because we usually want the regular instance based one. I am okay to add PersistentDict and PersistentMapping to the list. I am already feeling unsure about UserDict, because people might want the instance version instead. It is better to register the adapter for the specific cases of your application. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 12:27:50PM +, Reinout van Rees wrote: On 2009-07-13, Marius Gedminas mar...@gedmin.as wrote: Whatever grok does that interferes with coverage should be fixed. I did some more debugging. In the end it boils down to this: With z3c.testsetup, you can specify a zcml file at the top of your test file. z3c.testsetup creates a ZCMLLayer with that zcml file. I my test files, I had two separate zcml files (one registered a bit more than the other). So I ended up with two separate ZCMLLayer subclasses. And both did some grokking. So apparently the teardown of a ZCMLLayer subclass when going from one to the next isn't that clean. There *is* a warning in zope.testing that teardown isn't fully supported. Ah, that one. zope.testing supports test layers that muck up the global state irrepairably (by letting the layer's tearDown method raise NotImplementedError) and continues running the subsequent test layers in a fresh and squeaky-clean subprocess. Unfortunately, a separate process means separate coverage data tracking, and currently zope.testing doesn't support merging coverage data from several processes. Fortunately, the NotImplementedError in ZCMLLayer's tearDown is just a precaution, 99% of the time it is sufficient to run CleanUp.tearDown to get the global state restored to its pristine condition. You can indicate that it is safe by passing allow_teardown=True to ZCMLLayer's constructor. As a result: * the tests will run marginally faster (no subprocess overhead) * you will be able to use pdb in your tests (zope.testing disables pdb in a subprocess since it wants exclusive control over stdout) * you will be able to get accurate coverage tracing. Now, how you can convince z3c.testsetup to pass allow_teardown=True to the ZCMLLayer it constructs, I don't know. I've never used z3c.testsetup (although it sounds like an interesting library and I should check it out some day). ZCMLLayer's allow_teardown=True badly needs more publicity. Or maybe a ruthless dictator, decreeing that it shall be on by default from some near-future date. How I solved it: just use one zcml layer in z3c.testsetup and do some extra grokking in the test itself instead of in the second zcml file. That will work until you decide to introduce a new layer. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 3:36 PM, Marius Gedminasmar...@gedmin.as wrote: Fortunately, the NotImplementedError in ZCMLLayer's tearDown is just a precaution, 99% of the time it is sufficient to run CleanUp.tearDown to get the global state restored to its pristine condition. Keep in mind that a number of commonly-used ZCML directives stamp interfaces on classes; these aren't cleaned up with the general tear-down. If each layer stamps the same interfaces on the same classes, the only issue is ensuring that unit tests run first. If, however, you have different layers that may apply different sets of interfaces to different classes, you're may be relying on the process boundary as part of the required isolation. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Problem with POST and text/xml (work-around)
Problem: zope interprets POST requests with a Content-Type of text/xml to be xmlrpc requests. Work-around (requires Apache as a reverse proxy): use Apache to re-write the Content-Type header of the incoming request before it gets to zope using the following directives: SetEnvIfNoCase Content-Type text/xml XMLFLAG RequestHeader set Content-Type application/xml env=XMLFLAG Zope then sees text/xml requests as application/xml requests and the xml data can then be accessed via REQUEST['BODY']. Thanks to Michael H. for the assistance! Jonathan ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
