[Zope-Checkins] SVN: Zope/branches/haufe-legacy-integration/ Integration branch for Dieter's Haufe legacy
Log message for revision 99820: Integration branch for Dieter's Haufe legacy Changed: A Zope/branches/haufe-legacy-integration/ -=- ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/haufe-legacy-integration/ - Launchpad #373621: catching and logging exceptions that could cause
Log message for revision 99821:
- Launchpad #373621: catching and logging exceptions that could cause
leaking of worker threads
Changed:
U Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
U
Zope/branches/haufe-legacy-integration/src/ZServer/PubCore/ZServerPublisher.py
-=-
Modified: Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
===
--- Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
15:14:02 UTC (rev 99820)
+++ Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
15:22:15 UTC (rev 99821)
@@ -23,6 +23,9 @@
Features Added
++
+- Launchpad #373621: catching and logging exceptions that could cause
+ leaking of worker threads
+
- zExceptions.convertExceptionType: new API, breaking out conversion of
exception names to exception types from 'upgradeException'.
Modified:
Zope/branches/haufe-legacy-integration/src/ZServer/PubCore/ZServerPublisher.py
===
---
Zope/branches/haufe-legacy-integration/src/ZServer/PubCore/ZServerPublisher.py
2009-05-10 15:14:02 UTC (rev 99820)
+++
Zope/branches/haufe-legacy-integration/src/ZServer/PubCore/ZServerPublisher.py
2009-05-10 15:22:15 UTC (rev 99821)
@@ -11,11 +11,17 @@
#
##
+import logging
+
+LOG = logging.getLogger('ZServerPublisher')
+
class ZServerPublisher:
def __init__(self, accept):
+from sys import exc_info
from ZPublisher import publish_module
from ZPublisher.WSGIPublisher import publish_module as publish_wsgi
while 1:
+ try:
name, a, b=accept()
if name == Zope2:
try:
@@ -36,3 +42,5 @@
# TODO: Support keeping connections open.
a['wsgi.output']._close = 1
a['wsgi.output'].close()
+ except:
+LOG.error('exception caught', exc_info=True)
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/versions.cfg Added zope.principalregistry to the KGS, the package turns up as a dependency somewhere
Log message for revision 99822: Added zope.principalregistry to the KGS, the package turns up as a dependency somewhere Changed: U Zope/trunk/versions.cfg -=- Modified: Zope/trunk/versions.cfg === --- Zope/trunk/versions.cfg 2009-05-10 15:22:15 UTC (rev 99821) +++ Zope/trunk/versions.cfg 2009-05-10 15:22:55 UTC (rev 99822) @@ -109,6 +109,7 @@ zope.password = 3.5.1 zope.pagetemplate = 3.4.2 zope.principalannotation = 3.6.0 +zope.principalregistry = 3.7.0 zope.proxy = 3.5.0 zope.publisher = 3.6.4 zope.schema = 3.5.4 ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/haufe-legacy-integration/ - Launchpad #373621: catching and logging exceptions that could cause
Log message for revision 99823:
- Launchpad #373621: catching and logging exceptions that could cause
leaking of worker threads
Changed:
U Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
U Zope/branches/haufe-legacy-integration/src/Zope2/Startup/__init__.py
-=-
Modified: Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
===
--- Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
15:22:55 UTC (rev 99822)
+++ Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
15:28:15 UTC (rev 99823)
@@ -26,6 +26,9 @@
- Launchpad #373621: catching and logging exceptions that could cause
leaking of worker threads
+- Launchpad #373577: setting up standard logging earlier within the startup
+ phase for improving the analysis of startup errors
+
- zExceptions.convertExceptionType: new API, breaking out conversion of
exception names to exception types from 'upgradeException'.
Modified: Zope/branches/haufe-legacy-integration/src/Zope2/Startup/__init__.py
===
--- Zope/branches/haufe-legacy-integration/src/Zope2/Startup/__init__.py
2009-05-10 15:22:55 UTC (rev 99822)
+++ Zope/branches/haufe-legacy-integration/src/Zope2/Startup/__init__.py
2009-05-10 15:28:15 UTC (rev 99823)
@@ -86,6 +86,7 @@
self.setupServers()
# drop privileges after setting up servers
self.dropPrivileges()
+self.setupFinalLogging()
self.makeLockFile()
self.makePidFile()
self.setupInterpreter()
@@ -100,7 +101,6 @@
# after it has emitted ZServer messages.
logger.info('Ready to handle requests')
-self.setupFinalLogging()
self.sendEvents()
def run(self):
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/haufe-legacy-integration/ - Launchpad #373601: abort transaction before connection close in order to
Log message for revision 99824: - Launchpad #373601: abort transaction before connection close in order to prevent connection leaks in case of persistent changes after the main transaction is closed. Changed: U Zope/branches/haufe-legacy-integration/doc/CHANGES.rst U Zope/branches/haufe-legacy-integration/src/App/ZApplication.py -=- Modified: Zope/branches/haufe-legacy-integration/doc/CHANGES.rst === --- Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10 15:28:15 UTC (rev 99823) +++ Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10 15:33:08 UTC (rev 99824) @@ -24,11 +24,15 @@ ++ - Launchpad #373621: catching and logging exceptions that could cause - leaking of worker threads + leaking of worker threads. - Launchpad #373577: setting up standard logging earlier within the startup - phase for improving the analysis of startup errors + phase for improving the analysis of startup errors. +- Launchpad #373601: abort transaction before connection close in order to + prevent connection leaks in case of persistent changes after the main + transaction is closed. + - zExceptions.convertExceptionType: new API, breaking out conversion of exception names to exception types from 'upgradeException'. Modified: Zope/branches/haufe-legacy-integration/src/App/ZApplication.py === --- Zope/branches/haufe-legacy-integration/src/App/ZApplication.py 2009-05-10 15:28:15 UTC (rev 99823) +++ Zope/branches/haufe-legacy-integration/src/App/ZApplication.py 2009-05-10 15:33:08 UTC (rev 99824) @@ -80,4 +80,5 @@ self._jar = jar def __del__(self): +transaction.abort() self._jar.close() ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/haufe-legacy-integration/ - Launchpad #373583: ZODBMountPoint - fixed broken mount support and
Log message for revision 99825:
- Launchpad #373583: ZODBMountPoint - fixed broken mount support and
extended the test suite.
Changed:
U Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
U
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/MountedObject.py
U
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/tests/testMountPoint.py
-=-
Modified: Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
===
--- Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
15:33:08 UTC (rev 99824)
+++ Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
15:58:44 UTC (rev 99825)
@@ -23,6 +23,9 @@
Features Added
++
+- Launchpad #373583: ZODBMountPoint - fixed broken mount support and
+ extended the test suite.
+
- Launchpad #373621: catching and logging exceptions that could cause
leaking of worker threads.
Modified:
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/MountedObject.py
===
---
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/MountedObject.py
2009-05-10 15:33:08 UTC (rev 99824)
+++
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/MountedObject.py
2009-05-10 15:58:44 UTC (rev 99825)
@@ -59,9 +59,7 @@
factory = guarded_getattr(dispatcher, 'manage_addFolder')
factory(id)
o = context.restrictedTraverse(id)
-# Commit a subtransaction to assign the new object to
-# the correct database.
-transaction.savepoint(optimistic=True)
+context._p_jar.add(o.aq_base)
return o
def traverseOrConstruct(self, path, omit_final=0):
Modified:
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/tests/testMountPoint.py
===
---
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/tests/testMountPoint.py
2009-05-10 15:33:08 UTC (rev 99824)
+++
Zope/branches/haufe-legacy-integration/src/Products/ZODBMountPoint/tests/testMountPoint.py
2009-05-10 15:58:44 UTC (rev 99825)
@@ -83,6 +83,7 @@
databases = [TestDBConfig('test_main.fs', ['/']).getDB(),
TestDBConfig('test_mount1.fs', ['/mount1']).getDB(),
TestDBConfig('test_mount2.fs', ['/mount2']).getDB(),
+ TestDBConfig('test_mount3.fs', ['/i/mount3']).getDB(),
]
mount_points = {}
mount_factories = {}
@@ -102,13 +103,21 @@
root = conn.root()
root['Application'] = app = Application()
self.app = app
+install_products(app, 'ZCatalog', 'PluginIndexes', 'OFSP')
+# login
+from AccessControl.User import system
+from AccessControl.SecurityManagement import newSecurityManager
+newSecurityManager(None, system)
transaction.commit() # Get app._p_jar set
-manage_addMounts(app, ('/mount1', '/mount2'))
+manage_addMounts(app, ('/mount1', '/mount2', '/i/mount3'))
transaction.commit() # Get the mount points ready
def tearDown(self):
+# logout
+from AccessControl.SecurityManagement import noSecurityManager
+noSecurityManager()
App.config.setConfiguration(original_config)
transaction.abort()
self.app._p_jar.close()
@@ -120,6 +129,7 @@
def testRead(self):
self.assertEqual(self.app.mount1.id, 'mount1')
self.assertEqual(self.app.mount2.id, 'mount2')
+self.assertEqual(self.app.i.mount3.id, 'mount3')
def testWrite(self):
app = self.app
@@ -144,6 +154,7 @@
self.assertEqual(getMountPoint(self.app.mount1)._path, '/mount1')
self.assert_(getMountPoint(self.app.mount2) is not None)
self.assertEqual(getMountPoint(self.app.mount2)._path, '/mount2')
+self.assertEqual(getMountPoint(self.app.i.mount3)._path, '/i/mount3')
del self.app.mount2
self.app.mount2 = Folder()
self.app.mount2.id = 'mount2'
@@ -160,8 +171,13 @@
{'status': 'Ok',
'path': '/mount2',
'name': 'test_mount2.fs',
- 'exists': 1}]
-self.assertEqual(expected, status)
+ 'exists': 1},
+{'status': 'Ok',
+ 'path': '/i/mount3',
+ 'name': 'test_mount3.fs',
+ 'exists': 1},
+]
+self.assertEqual(sorted(expected), sorted(status))
del self.app.mount2
status = manage_getMountStatus(self.app)
expected = [{'status': 'Ok',
@@ -171,8 +187,14 @@
{'status': 'Ready to create',
'path': '/mount2',
'name': 'test_mount2.fs',
[Zope-Checkins] SVN: Zope/branches/haufe-legacy-integration/ - Launchpad #373658: traversal using (un)restrictedTraverse
Log message for revision 99829:
- Launchpad #373658: traversal using (un)restrictedTraverse
no longer depends no the existence of a request
Changed:
U Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
U Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
-=-
Modified: Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
===
--- Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
16:14:42 UTC (rev 99828)
+++ Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
19:12:43 UTC (rev 99829)
@@ -23,6 +23,9 @@
Features Added
++
+- Launchpad #373658: traversal using (un)restrictedTraverse
+ no longer depends no the existence of a request
+
- Launchpad #373583: ZODBMountPoint - fixed broken mount support and
extended the test suite.
Modified: Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
===
--- Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
2009-05-10 16:14:42 UTC (rev 99828)
+++ Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
2009-05-10 19:12:43 UTC (rev 99829)
@@ -154,6 +154,7 @@
path = list(path)
REQUEST = {'TraversalRequestNameStack': path}
+web_request = getattr(self, 'REQUEST', None)
path.reverse()
path_pop = path.pop
@@ -198,7 +199,7 @@
ns, nm = nsParse(name)
try:
next = namespaceLookup(
-ns, nm, obj, aq_acquire(self, 'REQUEST'))
+ns, nm, obj, web_request).__of__(obj)
if IAcquirer.providedBy(next):
next = next.__of__(obj)
if restricted and not validate(
@@ -264,7 +265,7 @@
except (AttributeError, NotFound, KeyError), e:
# Try to look for a view
-next = queryMultiAdapter((obj, aq_acquire(self,
'REQUEST')),
+next = queryMultiAdapter((obj, web_request),
Interface, name)
if next is not None:
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/haufe-legacy-integration/ reverted last checkin (breaking tests)
Log message for revision 99831:
reverted last checkin (breaking tests)
Changed:
U Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
U Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
-=-
Modified: Zope/branches/haufe-legacy-integration/doc/CHANGES.rst
===
--- Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-10
23:52:35 UTC (rev 99830)
+++ Zope/branches/haufe-legacy-integration/doc/CHANGES.rst 2009-05-11
04:25:37 UTC (rev 99831)
@@ -23,9 +23,6 @@
Features Added
++
-- Launchpad #373658: traversal using (un)restrictedTraverse
- no longer depends no the existence of a request
-
- Launchpad #373583: ZODBMountPoint - fixed broken mount support and
extended the test suite.
Modified: Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
===
--- Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
2009-05-10 23:52:35 UTC (rev 99830)
+++ Zope/branches/haufe-legacy-integration/src/OFS/Traversable.py
2009-05-11 04:25:37 UTC (rev 99831)
@@ -154,7 +154,6 @@
path = list(path)
REQUEST = {'TraversalRequestNameStack': path}
-web_request = getattr(self, 'REQUEST', None)
path.reverse()
path_pop = path.pop
@@ -199,7 +198,7 @@
ns, nm = nsParse(name)
try:
next = namespaceLookup(
-ns, nm, obj, web_request).__of__(obj)
+ns, nm, obj, aq_acquire(self, 'REQUEST'))
if IAcquirer.providedBy(next):
next = next.__of__(obj)
if restricted and not validate(
@@ -265,7 +264,7 @@
except (AttributeError, NotFound, KeyError), e:
# Try to look for a view
-next = queryMultiAdapter((obj, web_request),
+next = queryMultiAdapter((obj, aq_acquire(self,
'REQUEST')),
Interface, name)
if next is not None:
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] Using views for exceptions in Zope 2.12?
Sidnei da Silva wrote: On Sat, May 9, 2009 at 12:52 PM, Chris Withers ch...@simplistix.co.uk wrote: Hmm, so I would I register different views for a KeyError versus an AttributeError? I believe you need to make KeyError implement an interface to be able to register a view for it. What use would be a view for KeyError anyway. *wink* It's perfectly possible to register a view for a class instead of an interface. (Not that I am familiar with the new views for errors stuff). Laurence ___ 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] Using views for exceptions in Zope 2.12?
On May 9, 2009, at 11:52 AM, Chris Withers wrote: Hanno Schlichting wrote: Try following the description given in the changelog at http://svn.zope.org/Zope/branches/2.11/doc/CHANGES.txt?view=markup under Zope 3-based exception views. Hmm, so I would I register different views for a KeyError versus an AttributeError? Not unless you actually need different views for them, which you probably don't. In my experience, you only need a few, as described in change notes. One additional one that isn't mentioned in the change notes but that I use a lot is UserError (zope.exceptions.UserError). This is an exception to raise when you want to display an end-user error message. Most exceptions are really application errors and should be handled by a view for Exception that displays a system error message. Jim -- Jim Fulton 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 )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Sat May 9 12:00:00 2009 UTC to Sun May 10 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat May 9 20:53:51 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011667.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat May 9 20:55:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011668.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Sat May 9 20:57:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011669.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sat May 9 20:59:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011670.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Sat May 9 21:01:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011671.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sat May 9 21:04:03 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011672.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Sat May 9 21:06:03 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011673.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Sat May 9 21:08:04 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011674.html ___ 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] ZTK futures: one big package?
I was just thinking about the future of the ZTK, and in the past I have argued for not attempting to version the entire set of packages that currently comprises Zope 3 over time as ZTK releases. Instead, I have argued for promoting packages that have some life of their own (independent of the rest of the pile) into subprojects that have their own release cycles. Then outside projects such as Plone and Grok could depend on independent versions of such packages, giving them slightly more flexibility than requiring a version of the ZTK. Given that this suggestion has been met with skepticism, let me try another tact. Instead of thinking about it this way, could we think about it as *deflating* the current set of zope.* packages that do not currently have a meaningful life of their own into a single setuptools distribution named ZTK. This package would include most everything in zope.app*, plus things like zope.server, zope.publisher, and other things that just aren't useful outside of Zope-the-appserver, or which currently just depend on too much. This ZTK distribution would *not* include packages that already have a life of their own outside Zope such as zope.interface, zope.component, zope.configuration, zope.proxy, ZODB, etc. These packages would continue to have their own release cycles. Over time, we'd tease out the dependencies of packages that live in the ZTK distribution, making them useful outside without any dependency on the ZTK. The names of these packages could be arbitrary (they wouldn't need to retain their old zope.* names). Some backwards dependency shims would be added to the ZTK to prevent old imports from breaking, and the ZTK distribution would then just have a dependency on the thing that got broken out. I'm thinking that this would simplify things greatly for people who want to be consumers of truly independent Zope packages. There'd be exactly N of them available for download (where N is much less than 100, more like 20), plus the ZTK, which would have the rest of the pile in it over time. If someone wanted to use a forked version of a package that lived in the ZTK distribution, they'd either do so by teasing out the dependencies and making it truly independent or they'd just reroll a custom version of the entire ZTK distribution. Does this make any sense? - C - C ___ 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] ZTK futures: one big package?
Chris McDonough wrote: Given that this suggestion has been met with skepticism, let me try another tact. Instead of thinking about it this way, could we think about it as *deflating* the current set of zope.* packages that do not currently have a meaningful life of their own into a single setuptools distribution named ZTK. This ZTK distribution would *not* include packages that already have a life of their own outside Zope such as zope.interface, zope.component, zope.configuration, zope.proxy, ZODB, etc. These packages would continue to have their own release cycles. Yay! Big +1 from me... Over time, we'd tease out the dependencies of packages that live in the ZTK distribution, making them useful outside without any dependency on the ZTK. The names of these packages could be arbitrary (they wouldn't need to retain their old zope.* names). Some backwards dependency shims would be added to the ZTK to prevent old imports from breaking, and the ZTK distribution would then just have a dependency on the thing that got broken out. Well, if they just used their old zope.* names, no shims would be needed, right? If it works, don't break it so it doesn't work ;-) I'm thinking that this would simplify things greatly for people who want to be consumers of truly independent Zope packages. There'd be exactly N of them available for download (where N is much less than 100, more like 20), plus the ZTK, which would have the rest of the pile in it over time. If someone wanted to use a forked version of a package that lived in the ZTK distribution, they'd either do so by teasing out the dependencies and making it truly independent or they'd just reroll a custom version of the entire ZTK distribution. Does this make any sense? yes, totally in agreement. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] ZTK futures: one big package?
On 5/10/09 8:50 PM, Chris Withers wrote: Over time, we'd tease out the dependencies of packages that live in the ZTK distribution, making them useful outside without any dependency on the ZTK. The names of these packages could be arbitrary (they wouldn't need to retain their old zope.* names). Some backwards dependency shims would be added to the ZTK to prevent old imports from breaking, and the ZTK distribution would then just have a dependency on the thing that got broken out. Well, if they just used their old zope.* names, no shims would be needed, right? If it works, don't break it so it doesn't work ;-) When possible, sure. The situation I'm thinking about in particular when suggesting that we could rename some things is that the current *structure* of packaging is pretty messed up in some cases (zope.publisher vs. zope.app.publisher, or z3c.form vs. zope.formlib, for instance). It might make sense to reshuffle code around that currently lives in separate packages into a single more external logical library or framework that might have aspects of all of the individual packages without needing to carry along the baggage of the old packaging structure. When we move it out, it could have an arbitrary name and an arbitrary structure; shims could exist in the old locations within the ZTK to keep old code running. - C ___ 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] need help importing python class into zope 2.11.2
HI I'm new to zope and python, I wrote some basic python class and a test program using this class. The script is working fine when running python from command line. Now I want to uses this class inside zope, I tried to create the script, but it failed with the following error. Line 5: __init__ is an invalid variable name because it starts with _ Can I write a constructor with different name? Please advice what is the correct why to import this class to zope Thanks Dganit ___ 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 )
Re: [Zope] need help importing python class into zope 2.11.2
On 10.05.09 14:48, Dganit David wrote: HI I’m new to zope and python, I wrote some basic python class and a test program using this class. The script is working fine when running python from command line. Now I want to uses this class inside zope, I tried to create the script, but it failed with the following error. Line 5: __init__ is an invalid variable name because it starts with _ Can I write a constructor with different name? Please advice what is the correct why to import this class to zope PythonScripts are *not* a replacement for pure Python code. PythonScripts are restricted. Class definitions belong into trusted code (browser views, externals method or a Zope product). http://docs.zope.org/zope2/zdgbook/ -aj begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 )
