[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PageTemplates/ZopePageTemplate.py using zope.app.contenttypes
Log message for revision 65526: using zope.app.contenttypes Changed: U Zope/trunk/lib/python/Products/PageTemplates/ZopePageTemplate.py -=- Modified: Zope/trunk/lib/python/Products/PageTemplates/ZopePageTemplate.py === --- Zope/trunk/lib/python/Products/PageTemplates/ZopePageTemplate.py 2006-02-27 17:46:20 UTC (rev 65525) +++ Zope/trunk/lib/python/Products/PageTemplates/ZopePageTemplate.py 2006-02-27 17:59:20 UTC (rev 65526) @@ -20,7 +20,7 @@ import Acquisition from Globals import ImageFile, package_home, InitializeClass from OFS.SimpleItem import SimpleItem -from OFS.content_types import guess_content_type +from zope.app.contenttypes import guess_content_type from DateTime.DateTime import DateTime from Shared.DC.Scripts.Script import Script from Shared.DC.Scripts.Signature import FuncCode ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/ZPublisher/ We don't need to do any real input processing if we are handling a PUT request because in practice, the body is never mime-encoded. This is an op
Log message for revision 65541:
We don't need to do any real input processing if we are handling a PUT
request because in practice, the body is never mime-encoded. This is an
optimization especially because FieldStorage creates an additional tempfile if
we allow it to parse the body, and PUT uploads can tend to be large.
In particular, this will be important for upload of large blobs.
Changed:
U Zope/trunk/lib/python/ZPublisher/HTTPRequest.py
U Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py
-=-
Modified: Zope/trunk/lib/python/ZPublisher/HTTPRequest.py
===
--- Zope/trunk/lib/python/ZPublisher/HTTPRequest.py 2006-02-27 22:21:54 UTC
(rev 65540)
+++ Zope/trunk/lib/python/ZPublisher/HTTPRequest.py 2006-02-27 22:27:29 UTC
(rev 65541)
@@ -375,6 +375,15 @@
environ=self.environ
method=environ.get('REQUEST_METHOD','GET')
+if method == 'PUT':
+# we don't need to do any real input processing if we are handling
+# a PUT request because in practice, the body is never
+# mime-encoded. This is an optimization especially because
+# FieldStorage creates an additional tempfile if we allow it to
+# parse the body, and PUT uploads can tend to be large.
+self._file = self.stdin
+return
+
if method != 'GET': fp=self.stdin
else: fp=None
Modified: Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py
===
--- Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py 2006-02-27
22:21:54 UTC (rev 65540)
+++ Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py 2006-02-27
22:27:29 UTC (rev 65541)
@@ -14,11 +14,11 @@
class ProcessInputsTests(unittest.TestCase):
-def _getHTTPRequest(self, env):
+def _getHTTPRequest(self, env, stdin=None):
from ZPublisher.HTTPRequest import HTTPRequest
-return HTTPRequest(None, env, None)
+return HTTPRequest(stdin, env, None)
-def _processInputs(self, inputs):
+def _processInputs(self, inputs, extraenv=None, stdin=None):
# Have the inputs processed, and return a HTTPRequest object holding
the
# result.
# inputs is expected to be a list of (key, value) tuples, no CGI
@@ -32,7 +32,9 @@
env = {'SERVER_NAME': 'testingharnas', 'SERVER_PORT': '80'}
env['QUERY_STRING'] = query_string
-req = self._getHTTPRequest(env)
+if extraenv is not None:
+env.update(extraenv)
+req = self._getHTTPRequest(env, stdin)
req.processInputs()
self._noFormValuesInOther(req)
return req
@@ -154,6 +156,15 @@
self._noTaintedValues(req)
self._onlyTaintedformHoldsTaintedStrings(req)
+def testPUTShortcut(self):
+# PUT requests are not fed through cgi.FieldStorage because
+# their bodies are never (in practice, anyway) MIME-encoded, and
+# we don't want FieldStorage to create a separate tempfile copy for
+# large uploads.
+stdin = []
+req = self._processInputs((), {'REQUEST_METHOD':'PUT'}, stdin)
+self.assert_(req._file is stdin)
+
def testUnicodeConversions(self):
inputs = (('ustring:ustring:utf8', 'test\xc2\xae'),
('utext:utext:utf8', 'test\xc2\xae\ntest\xc2\xae\n'),
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/doc/CHANGES.txt
Log message for revision 65542: Changed: U Zope/trunk/doc/CHANGES.txt -=- Modified: Zope/trunk/doc/CHANGES.txt === --- Zope/trunk/doc/CHANGES.txt 2006-02-27 22:27:29 UTC (rev 65541) +++ Zope/trunk/doc/CHANGES.txt 2006-02-27 22:28:47 UTC (rev 65542) @@ -26,6 +26,10 @@ Restructuring + - REQUEST.processInputs now shortcuts the creation of a cgi.FieldStorage +object if the request is a PUT request. This is an optimization +for large uploads. + - deprecated the zLOG module. Use Pythons 'logging' module instead. - replaced all zLOG occurences (expect the zLOG module itself) with ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Revert changes made in revision 65541 in favor of moving them to the blob-integration-test branch for eventual merge.
Log message for revision 65553:
Revert changes made in revision 65541 in favor of moving them to the
blob-integration-test branch for eventual merge.
Changed:
U Zope/trunk/doc/CHANGES.txt
U Zope/trunk/lib/python/ZPublisher/HTTPRequest.py
U Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py
-=-
Modified: Zope/trunk/doc/CHANGES.txt
===
--- Zope/trunk/doc/CHANGES.txt 2006-02-28 00:14:38 UTC (rev 65552)
+++ Zope/trunk/doc/CHANGES.txt 2006-02-28 00:27:35 UTC (rev 65553)
@@ -26,10 +26,6 @@
Restructuring
- - REQUEST.processInputs now shortcuts the creation of a cgi.FieldStorage
-object if the request is a PUT request. This is an optimization
-for large uploads.
-
- deprecated the zLOG module. Use Pythons 'logging' module instead.
- replaced all zLOG occurences (expect the zLOG module itself) with
Modified: Zope/trunk/lib/python/ZPublisher/HTTPRequest.py
===
--- Zope/trunk/lib/python/ZPublisher/HTTPRequest.py 2006-02-28 00:14:38 UTC
(rev 65552)
+++ Zope/trunk/lib/python/ZPublisher/HTTPRequest.py 2006-02-28 00:27:35 UTC
(rev 65553)
@@ -375,15 +375,6 @@
environ=self.environ
method=environ.get('REQUEST_METHOD','GET')
-if method == 'PUT':
-# we don't need to do any real input processing if we are handling
-# a PUT request because in practice, the body is never
-# mime-encoded. This is an optimization especially because
-# FieldStorage creates an additional tempfile if we allow it to
-# parse the body, and PUT uploads can tend to be large.
-self._file = self.stdin
-return
-
if method != 'GET': fp=self.stdin
else: fp=None
Modified: Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py
===
--- Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py 2006-02-28
00:14:38 UTC (rev 65552)
+++ Zope/trunk/lib/python/ZPublisher/tests/testHTTPRequest.py 2006-02-28
00:27:35 UTC (rev 65553)
@@ -14,11 +14,11 @@
class ProcessInputsTests(unittest.TestCase):
-def _getHTTPRequest(self, env, stdin=None):
+def _getHTTPRequest(self, env):
from ZPublisher.HTTPRequest import HTTPRequest
-return HTTPRequest(stdin, env, None)
+return HTTPRequest(None, env, None)
-def _processInputs(self, inputs, extraenv=None, stdin=None):
+def _processInputs(self, inputs):
# Have the inputs processed, and return a HTTPRequest object holding
the
# result.
# inputs is expected to be a list of (key, value) tuples, no CGI
@@ -32,9 +32,7 @@
env = {'SERVER_NAME': 'testingharnas', 'SERVER_PORT': '80'}
env['QUERY_STRING'] = query_string
-if extraenv is not None:
-env.update(extraenv)
-req = self._getHTTPRequest(env, stdin)
+req = self._getHTTPRequest(env)
req.processInputs()
self._noFormValuesInOther(req)
return req
@@ -156,15 +154,6 @@
self._noTaintedValues(req)
self._onlyTaintedformHoldsTaintedStrings(req)
-def testPUTShortcut(self):
-# PUT requests are not fed through cgi.FieldStorage because
-# their bodies are never (in practice, anyway) MIME-encoded, and
-# we don't want FieldStorage to create a separate tempfile copy for
-# large uploads.
-stdin = []
-req = self._processInputs((), {'REQUEST_METHOD':'PUT'}, stdin)
-self.assert_(req._file is stdin)
-
def testUnicodeConversions(self):
inputs = (('ustring:ustring:utf8', 'test\xc2\xae'),
('utext:utext:utf8', 'test\xc2\xae\ntest\xc2\xae\n'),
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/blob-integration-test/lib/python/ZPublisher/ We don't need to do any real input processing if we are handling a PUT request because in practice, the body is never m
Log message for revision 65554:
We don't need to do any real input processing if we are handling a PUT
request because in practice, the body is never mime-encoded. This is an
optimization especially because FieldStorage creates an additional tempfile if
we allow it to parse the body, and PUT uploads can tend to be large.
In particular, this will be important for upload of large blobs.
Changed:
U Zope/branches/blob-integration-test/lib/python/ZPublisher/HTTPRequest.py
U
Zope/branches/blob-integration-test/lib/python/ZPublisher/tests/testHTTPRequest.py
-=-
Modified:
Zope/branches/blob-integration-test/lib/python/ZPublisher/HTTPRequest.py
===
--- Zope/branches/blob-integration-test/lib/python/ZPublisher/HTTPRequest.py
2006-02-28 00:27:35 UTC (rev 65553)
+++ Zope/branches/blob-integration-test/lib/python/ZPublisher/HTTPRequest.py
2006-02-28 00:29:14 UTC (rev 65554)
@@ -375,6 +375,15 @@
environ=self.environ
method=environ.get('REQUEST_METHOD','GET')
+if method == 'PUT':
+# we don't need to do any real input processing if we are handling
+# a PUT request because in practice, the body is never
+# mime-encoded. This is an optimization especially because
+# FieldStorage creates an additional tempfile if we allow it to
+# parse the body, and PUT uploads can tend to be large.
+self._file = self.stdin
+return
+
if method != 'GET': fp=self.stdin
else: fp=None
Modified:
Zope/branches/blob-integration-test/lib/python/ZPublisher/tests/testHTTPRequest.py
===
---
Zope/branches/blob-integration-test/lib/python/ZPublisher/tests/testHTTPRequest.py
2006-02-28 00:27:35 UTC (rev 65553)
+++
Zope/branches/blob-integration-test/lib/python/ZPublisher/tests/testHTTPRequest.py
2006-02-28 00:29:14 UTC (rev 65554)
@@ -14,11 +14,11 @@
class ProcessInputsTests(unittest.TestCase):
-def _getHTTPRequest(self, env):
+def _getHTTPRequest(self, env, stdin=None):
from ZPublisher.HTTPRequest import HTTPRequest
-return HTTPRequest(None, env, None)
+return HTTPRequest(stdin, env, None)
-def _processInputs(self, inputs):
+def _processInputs(self, inputs, extraenv=None, stdin=None):
# Have the inputs processed, and return a HTTPRequest object holding
the
# result.
# inputs is expected to be a list of (key, value) tuples, no CGI
@@ -32,7 +32,9 @@
env = {'SERVER_NAME': 'testingharnas', 'SERVER_PORT': '80'}
env['QUERY_STRING'] = query_string
-req = self._getHTTPRequest(env)
+if extraenv is not None:
+env.update(extraenv)
+req = self._getHTTPRequest(env, stdin)
req.processInputs()
self._noFormValuesInOther(req)
return req
@@ -154,6 +156,15 @@
self._noTaintedValues(req)
self._onlyTaintedformHoldsTaintedStrings(req)
+def testPUTShortcut(self):
+# PUT requests are not fed through cgi.FieldStorage because
+# their bodies are never (in practice, anyway) MIME-encoded, and
+# we don't want FieldStorage to create a separate tempfile copy for
+# large uploads.
+stdin = []
+req = self._processInputs((), {'REQUEST_METHOD':'PUT'}, stdin)
+self.assert_(req._file is stdin)
+
def testUnicodeConversions(self):
inputs = (('ustring:ustring:utf8', 'test\xc2\xae'),
('utext:utext:utf8', 'test\xc2\xae\ntest\xc2\xae\n'),
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/blob-integration-test/lib/python/ - updated eternals
Log message for revision 65575: - updated eternals Changed: _U Zope/branches/blob-integration-test/lib/python/ -=- Property changes on: Zope/branches/blob-integration-test/lib/python ___ Name: svn:externals - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/BTrees persistent -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/persistent ThreadedAsync -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ThreadedAsync transaction-r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/transaction ZEO-r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZEO ZODB -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZODB ZopeUndo -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZopeUndo zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode ClientCookie -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie mechanize -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize docutils -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/docutils + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees svn://svn.zope.org/repos/main/ZODB/branches/blob-merge-branch/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/branches/blob-merge-branch/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/branches/blob-merge-branch/src/ThreadedAsync transaction svn://svn.zope.org/repos/main/ZODB/branches/blob-merge-branch/src/transaction ZEO svn://svn.zope.org/repos/main/ZODB/branches/blob-merge-branch/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/branches/blob-merge-branch/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/branches/blob-merge-branch/src/ZopeUndo zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode ClientCookie -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie mechanize -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize docutils -r 41215 svn://svn.zope.org/repos/main/Zope3/trunk/src/docutils ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/blob-integration-test/skel/etc/zope.conf.in - Made skeleton include hints about blobs
Log message for revision 65576: - Made skeleton include hints about blobs Changed: U Zope/branches/blob-integration-test/skel/etc/zope.conf.in -=- Modified: Zope/branches/blob-integration-test/skel/etc/zope.conf.in === --- Zope/branches/blob-integration-test/skel/etc/zope.conf.in 2006-02-28 02:28:25 UTC (rev 65575) +++ Zope/branches/blob-integration-test/skel/etc/zope.conf.in 2006-02-28 02:32:22 UTC (rev 65576) @@ -106,6 +106,7 @@ # #environment # MY_PRODUCT_ENVVAR foobar +# ZODB_BLOB_TEMPDIR /tmp #/environment # Directive: debug-mode @@ -995,6 +996,39 @@ # #client zeo1 # /zeoclient # /zodb_db +# +# Blob storage: +# +# zodb_db main +# mount-point / +# # ZODB cache, in number of objects +# cache-size 5000 +# blobstorage +# blob-dir $INSTANCE/var/blobs +# filestorage +# path $INSTANCE/var/Data.fs +# /filestorage +# /blobstorage +# /zodb_db +# +# ZEO with blobs: +# +# zodb_db main +# mount-point / +# # ZODB cache, in number of objects +# cache-size 5000 +# zeoclient +# server localhost:8100 +# storage 1 +# name zeostorage +# var $INSTANCE/var +# # ZEO client cache, in bytes +# cache-size 20MB +# blob-dir $INSTANCE/var/blobs +# # Uncomment to have a persistent disk cache +# #client zeo1 +# /zeoclient +# /zodb_db # Product configuration (product-config) section(s) # ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] [ANN] pythonproducts 1.0alpha1 released
Hi all, I've now made available the first public release of pythonproducts. pythonproducts == Description A mechanism to construct Zope 2 products as regular python packages. This enables a python package to be deployed as a Zope 2 product using a similar strategy as Zope 3. Author/Maintainer `Rocky Burt [EMAIL PROTECTED]`__ Latest Release `1.0alpha1 http://dev.serverzen.com/site/projects/pythonproducts/releases/pythonproducts-1-0alpha1-tar.gz/download`__ License BSD-style, see LICENSE.txt for details Source Control http://codespeak.net/svn/z3/pythonproducts/ Requirements - Python 2.3.5 or higher in 2.3.x series - Zope 2.8.4 or higher in 2.8.x series - Five 1.2 or higher Installing Uses regular python distutils for installation. Simply run:: ./setup.py install --home /some/path/to/zope_instance_home Usage Once pythonproducts has been installed, the standard practise of installing a python package as a Zope 2 product is as follows: 1. edit (or create it if it doesn't exist already) ``$YOUR_PKG_SOURCE/configure.zcml`` and add the line ``five:registerPackage package=. initialize=.initialize /`` 2. copy your python package to ``$INSTANCE_HOME/lib/python`` 3. create a ZCML slug by creating the file `` $INSTANCE_HOME/etc/package-includes/yourpackage-configure.zcml`` and populating it with ``configure package=yourpackage /`` Explanation of Usage Step 1: Your python package needs to register itself as a Zope 2 product. This is accomplished by using the new ``registerPackage`` directive. This directive takes a (required) package attribute which declares any python package as a Zope 2 product (with . meaning this package). Another (optional) attribute is the 'initialize' attribute. If this attribute is defined, a function with that name will be invoked in a traditional Zope 2 style with a ProductContext instance as the sole argument. Step 2: Your python package needs to exist *somewhere* on PYTHONPATH. With Zope 2.8, $INSTANCE_HOME/lib/python is added to the PYTHONPATH so copying your python package there ensures its somewhere in PYTHONPATH. But really your python package could be copied to any directory that exists on PYTHONPATH (ie /usr/lib/python2.3/site-packages). Step 3: The standard way of registering a package with Zope 3 is to create a ZCML slug in the $INSTANCE_HOME/etc/package-includes directory. This file can be called anything as long as it ends with -configure.zcml. -- Rocky Burt AdaptiveWave - Consulting, Training, and Content Management as a Service http://www.adaptivewave.com Content Management Made Simple ___ 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: [Zope3-dev] Re: [Zope-dev] Release schedule and deprecation decisions
On Mon, 2006-02-06 at 09:58 +0100, Christian Theune wrote: Hi, On Sun, 2006-02-05 at 12:11 -0500, Jim Fulton wrote: A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. ... Yikes. I do support the general decision, although this mangles my schedule about getting ready with the CC implemetation. +1 Thinking about this some more, I propose we should go for June and November this year, to give Christian and others more time and then do May and November from there on. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Two visions
I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 - There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.) - Eventually, the gap between Zope 2 and will become very small. requiring a small leap. In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) Advantages of this vision: - Zope 2 users don't need to leave Zope 2. - Zope 3 doesn't have to reproduce all Zope 2 features. - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. Thoughts? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Re: [Zope3-dev] Two visions
On Mon, 2006-02-27 at 10:37 -0500, Jim Fulton wrote: I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 - There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.) - Eventually, the gap between Zope 2 and will become very small. requiring a small leap. In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. -1 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) Advantages of this vision: - Zope 2 users don't need to leave Zope 2. - Zope 3 doesn't have to reproduce all Zope 2 features. - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. Thoughts? +2 I personally think that one of the great things about what has come out of Zope 3 development: other projects can use the technologies without taking Zope 3 lock stock and barrel. I'd hate to see Zope 3 get more girth and loose future traction because it had to be fully backwards compatible with Zope 2. For those who wish to slowly migrate to using Zope 3 technologies without completely rewriting their software, evolving via Five is a fair approach. To quote a blog I'd read earlier today: Doing little things well is a step towards doing big things better. Allowing others to assist in refining the little technologies which make up Zope 3 can achieve this goal. I would fear this would be impossible if the first vision was followed. Andrew Sawyers Jim ___ 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] Re: [Zope3-dev] Two visions
My 2 EuroCents: Vision 1 is, I think what is happening at the moment for pragamatic and practical reasons. Drawbacks of this is that we loose the ZopeX3 (Zope3X?) vision of cutting loose from old burdens and take off to new horizons. Vision 2, on the other hand (at least to me in my not-really-started-with-z3-development-yet situation), is a lot more appealing for a variety of reasons, not the least that choosing working development model (zope2 and zope3 for starters, there may be others) becomes a configuration(*) issue. The potential benefits of this approach are very appealing (almost like eating the cake and still having it :), so I vote for vision 2. /dario (*) Configuration in a broad sense: mind model, conf-files, development model, etc... -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. Lyrics applied to programming application design: emancipate yourself from mental slavery - redemption song, b. marley ___ 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] Two visions
OK, some initial, fuzzy comments: On 2/27/06, Jim Fulton [EMAIL PROTECTED] wrote: In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. You are thinking about things like TTW development and such? Because I see that as add-on products of different kinds. Like cpsskins to develop the look, and some sort of persistent schemas combined with some sort of aspect-oriented classes. ;-) If there is some sort of real core thingy that you lose going from Zope2 to Zope3 I must have missed it. :-p 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. This overwhelms my complexity sensor. :-) I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not. - There wouldn't be confusion about 2 Zopes. This is definitely true... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [Zope3-dev] Re: Two visions
Max M said the following on 2006-02-27 17:26: Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Zope 2 is complicated! It has too many layers of everything. read the full sentence that Jim wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. ... Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. In this scenario I cannot see how much of the old ways of zope2 remain (unless I have a totally unrealistic view of what Jim proposes). zope 2 or zop3 become an issue of configuring which components/parts to use. /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. Lyrics applied to programming application design: emancipate yourself from mental slavery - redemption song, b. marley ___ 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] Re: [Zope3-dev] Re: Two visions
Max M wrote: Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Zope 2 is complicated! It has too many layers of everything. Layers are good, when they reliably hide complexity. The reason for Zope 3 is to make it simpler for developers. Yep. 14'30'' wikis and such. Therefore I believe that any succesfull strategy would require Zope 3 to be usable completely without all the Zope 2 layers. If Zope 3 becomes just another layer on top of Zope 2 - CMF - Plone it will not reduce complexity, as any developer would still need to learn the entire stack. You mean, on top - below ? (And Plone - CPS ;) ). Wherever practical, Zope 2 technologies should be rewritten to Zope 3 technologies to remove layers from the stack. To make discussion concrete, is there a list of (core, not CMF) Zope 2 technologies that are currently missing from Zope 3 ? S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ 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] Re: Two visions
Dario Lopez-Kästen wrote: Max M said the following on 2006-02-27 17:26: Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Zope 2 is complicated! It has too many layers of everything. read the full sentence that Jim wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. ... Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. In this scenario I cannot see how much of the old ways of zope2 remain (unless I have a totally unrealistic view of what Jim proposes). zope 2 or zop3 become an issue of configuring which components/parts to use. But he also says: - Zope 3 doesn't have to reproduce all Zope 2 features. Which i fear could mean that the Zope 2 stack will hang in there for ever. I am pretty shure that is not what he meant meant to imply, I just wanted to make my view clear. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ 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] Re: Two visions
Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. +1 as already discussed at PyCON. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'. Then again, I really should take Jim's side and stay out of naming decisions. Advantages of this vision: - Zope 2 users don't need to leave Zope 2. - Zope 3 doesn't have to reproduce all Zope 2 features. - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. I'll note that while Zope will remain to be the application server (in its Zope 5 incarnation), you should and would still be able to create WSGI-capable object-publishing applications with the Zed pieces fairly easily, for example when you don't need the full-blown Zope experience. I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed. A Zope distribution would include a fair number of Zed eggs and the Zope-specific things should live under the 'Zope2' namespace package. Fortunately we're already starting with cleaning up some of the top-level packages (zLOG, TAL, StructuredText) in Zope 2.10. Philipp ___ 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] Re: Two visions
On Tue, Feb 28, 2006 at 12:31:33AM +0100, Philipp von Weitershausen wrote: I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed. +sys.maxint I think this will be the way we get a real forward migration path for an awful lot of us who are still using Zope 2 today, and expect to continue doing so. We may or may not ever port to zope 3, whatever that will mean in the future. More likely we will just incrementally improve and clean up our applications, just as Zope 2 itself will be getting incrementally better and cleaner. We'll have to address deprecation warnings at each upgrade, but at no point will we be forced to do a complete rewrite. And along the way, we'll be gradually getting access to more and more nifty features. -- Paul Winkler http://www.slinkp.com ___ 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: [Zope3-dev] Re: [Zope-dev] Release schedule and deprecation decisions
On Monday 27 February 2006 09:31, Jim Fulton wrote: Thinking about this some more, I propose we should go for June and November this year, to give Christian and others more time and then do May and November from there on. +1 This way the Easter sprint could contribute to the release. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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] Re: [Zope3-dev] Two visions
On Monday 27 February 2006 10:37, Jim Fulton wrote: 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 2) In an alternate vision, Zope 2 evolves to Zope 5. As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code. Anyways, since I think the vision has too littel technical detail for my taste, I would really like to see some prototyping before I give my final vote. I just want to be ensured that I do not have to deal with additional overhead (i.e. learn Zope 2 again), but can develop Zope 3 applications as I like it. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: [Zope3-dev] Re: [Zope-dev] Two visions
On Monday 27 February 2006 11:06, Lennart Regebro wrote: I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not. That would sound good to me!!! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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] Re: [Zope3-dev] Two visions
On Feb 27, 2006, at 10:37 AM, Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Of the two, this seems more believable. It also may be the best we can do. However, I still don't like it. :-) - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. This is reasonable, though I don't love it. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. This gets to the heart of my concern, I guess (see below). Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. You say that one of the advantages of this vision is that There wouldn't be confusion about 2 Zopes. I'm afraid that's wishful thinking, if you want Zope 5 to include a Zope 3-like web configuration. If you are going to pursue a Zope Five and the artist formerly known as Zope 3 vision, in which Zope is a single clear product, then it seems to me that Zope Five should be one or the other, and that's what books should describe. A Zope 2 derivative a la Five makes sense, given Zope's history and current users. More below. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. There are some--Steve Alexander and Canonical, maybe?--who might not care about anything beyond choosing among the bag of technologies. But I assert with the right of speaking loudly (i.e., I have no way to prove this) that there are many who appreciate the bag of components design who still want to buy into some of the Zope 3 as web application server story. For instance, if you mean by a Zope 2-like application server an Object File System approach then I certainly hope you are wrong. Even though I don't care much about the Zope 3 ZMI, Zope 3 encapsulates some web app design decisions I would be loathe to lose. I much prefer the Zope 3 approach to OFS, with __parent__ rather than acquisition wrappers, a dict interface rather than objectValues and friends, and traversal adapters rather than __bobo_traverse__ and friends. If acquisition and all the rest are on the way to being replaced within Zope 2/5, then...yay? but then how is it still Zope 2 backward compatible? They seem core to Zope 2 to me. And the Zope 3 versions of the decisions inform many Zope 3 component designs. Do you mean that the Zope 3 users don't need Zope 2 cataloging and indexing? Surely not, and yet again moving Zope Five to the Zope 3 catalog seems pretty questionable as Zope 2 backward compatible. And I *much* prefer the zope.index/zope.app.keyref/zope.app.intid combo in Zope 3. Do you mean that Zope 3 users aren't looking for a better designed web app than Zope 2, that looks less long-in-the-tooth (as I've seen blogs call Zope 2), that has more industrial-strength flexibility and hard-won design experience than the current crop of competitors? I don't think so: I assert that developers of a certain inclination are attracted to the cleanliness of Zope 3 as a web app, and not as attracted to the cruft that accumulates in an older, very successful project like Zope 2. Some of those are new Zope developers, and some are prominent older Zope developers. Do you mean that Zope 3 users don't want a robust, battle-hardened web publisher like the Zope 2 publisher? I think many do. So, I assert that many Zope 3 users, who are in it for the bag of components, *do* want a web application server. If I'm misunderstanding you, then, as Stephan said, maybe you could explain more. (Almost done, but still more below) Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) If this is the plan, then I guess I
Re: [Zope-dev] ImageFile weirdness?
Jürgen Herrmann wrote:
On Thu, February 23, 2006 09:02, Chris Withers wrote:
1. why the 3 posts?
sorry, there was a long delay before my messages appeared, so i thought
i had problems with my subscription. sorry for the triple post!
Good grief, please check the archives to see where your message is, and
check your mta logs first...
2. Why on [EMAIL PROTECTED] This should be on zope@zope.org
well, actually i have a specific question about ImageFile internals here,
thought it would fit in best here, if not - sorry.
Okay, lets here it then...
image = ImageFile('1.gif', '/some/where')
setattr(self.__class__, '1.gif', image)
3. Arrgh?! What _are_ you trying to do here?
what are you trying to say here?
this is totally unrelated to my actual problem.
Yes, but it's insane code. This will cause lots of problems, and may
even be behind your actual problem, which you fail to describe...
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] Zope 2.9 releases for Windows?
Sidnei da Silva wrote: Basically you need (a properly licensed) VC 7, and Python 2.4.2 installed. Not much else has changed. Unfortunately we haven't gotten around setting up VC 7 here. Okay, once I have those two, then what do I do to end up with a binary distro for Zope 2.9.1? cheers, 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] Zope scheduling problem
On 2/24/06, Nicholas Watmough [EMAIL PROTECTED] wrote: Out of interest, why am I unable to access the method from with my Zope python code? What is a private object, and why is it private? All through-the-web code is run in a restricted sandbox; this includes Python Scripts, DTML methods, ZSQL methods and Page Templates. Any access to non-restricted code (Zope Products, the Zope framework itself, External Methods) is governed by the Zope security system, and the permissions set. 'Private' is the label given to code that cannot, ever, be directly called from restricted code. The method in question is private because it bypasses the security restrictions imposed by the regular version. -- Martijn Pieters ___ 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 )
[Zope] webdav and PUT_factory
First of all, I would like to thank everybody for your accurate and fast answers. I am working with a small group of developers, each in different places and working at different times. According to my past experience in java, this means cvs ^_^ I have some doubts about how to synchronize Zope development with cvs or subversion. Should I stop using the ZMI? Should I develop a Zope Product instead? Should I use fsdump instead of webdav to export from zope ? Should I use webdav when deploying back to Zope? This is my actual state-of-the-art about team management in Zope : We develop inside locally installed Zope Instances, using the ZMI. At the end of the day, we export the work done using webdav, and this works for DTML documents, DTML methods and ZSQL methods. After that, we commit inside the source code repository, using the update, diff and merge features to synchronize with other developers' work. We need to deploy to a Zope server in order to test the integration of developers' code, so I wrote a little PUT_factory to re-create the right objects, this is a snippet: elif ext == 'zsql': from Products.ZSQLMethods.SQL import SQL return SQL(name, '', 'daticonvegno', '' ,'') elif ext == 'dtml': from OFS.DTMLDocument import DTMLDocument return DTMLDocument( '', __name__=name ) elif ext == 'dtmm': from OFS.DTMLMethod import DTMLMethod return DTMLMethod( '', __name__=name ) elif major == 'text': from OFS.DTMLDocument import DTMLDocument return OFS.DTMLDocument.DTMLDocument( '', __name__=name ) As you can see, it uses extensions to understand the type of the file. This has some minor drawbacks : 1) you have to use extensions to make it work, otherwise you will have trouble at deploy-time 2) some additional parameters such as the connectionIds for ZSQLMethods must be auto-magically chosen by the PUT_factory 3) what about more complex objects, such as Plone, Archetypes or Openflow? should I map them all in the PUT_factory? Is this the right way to do things in Zope? Is there any native solution for Source Code Versioning and Team Management? How do other team solve this issue? Any advice is welcome! Thank you very much in advance, Luca ___ 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] Dates off by one day
It is likely to be a problem with timezones. Zope recognizes one particular date format as UTC and not local. If that sounds like the problem, I can provide a patch. On Sat, 25 Feb 2006, Kevin Carlson wrote: Recently moved to a new server farm and am having a problem with dates from MySQL that are rendered using strftime. The date in MySQL is correct (e.g. 2005-01-22) but if the date is rendered with strftime the date displayed is one day earlier (e.g., 2005-01-21). MySQL and Zope are on separate servers as they were before the switch to the new servers but this didn't happen in the old environment. Anyone have any thoughts on this? Thanks, Kevin ___ 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 ) -- ___ 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 )
[Zope] Dynamic dictionary keys?
Allow me to preface this by saying I am a complete newbie to Zope (I
prefer to think of it as beginner's mind...). What I am attempting
to do is dynamically add items to a dictionary, but Zope complains
keyword can't be an expression. Here's the reduced case of my code:
dtml-let eventsDict={}
dtml-let calstart=somestring
dtml-call REQUEST.set(eventsDict[calstart]=id)
/dtml-let
/dtml-let
This kind of construct *seems* perfectly reasonable, yet it doesn't
work. Any suggestions? Other possible ways of doing the same thing?
Thanks!
-Andrew
-
Andrew Hedges, Clearwired Web Services
[EMAIL PROTECTED] / http://clearwired.com/
___
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] Dynamic dictionary keys?
- Original Message -
From: Andrew Hedges [EMAIL PROTECTED]
To: zope@zope.org
Sent: Monday, February 27, 2006 11:56 AM
Subject: [Zope] Dynamic dictionary keys?
Allow me to preface this by saying I am a complete newbie to Zope (I
prefer to think of it as beginner's mind...). What I am attempting
to do is dynamically add items to a dictionary, but Zope complains
keyword can't be an expression. Here's the reduced case of my code:
dtml-let eventsDict={}
dtml-let calstart=somestring
dtml-call REQUEST.set(eventsDict[calstart]=id)
/dtml-let
/dtml-let
It is much easier in python script, but if you really want to use dtml:
dtml-call REQUEST.set('eventsDict', {})
dtml-call eventsDict.update({'calstart' : id})
hth
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 )
Re: [Zope] Dynamic dictionary keys?
On 27.02.06 09:56:49, Andrew Hedges wrote:
Allow me to preface this by saying I am a complete newbie to Zope (I prefer
to
think of it as beginner's mind...). What I am attempting to do is
dynamically
add items to a dictionary, but Zope complains keyword can't be an
expression.
Here's the reduced case of my code:
dtml-let eventsDict={}
dtml-let calstart=somestring
dtml-call REQUEST.set(eventsDict[calstart]=id)
/dtml-let
/dtml-let
First let me tell you: Write a python script for things like this, it
really belongs into one.
Second thing: your dtml-call has a serious error, eventsDict[..]=id is
executed but it doesn't produce anything so set is called with no
parameters and this is wrong. set needs 2 parameters, one beeing a
string as the key and a second as the value which can be of any type
python knows.
I also don't get what this snippet should do?
Andreas
--
Today is the first day of the rest of your life.
___
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] Dynamic dictionary keys?
Andreas and Jonathan,
Thanks for the responses! As I said, I am completely new to Zope/
Python, so I appreciate your help. I'll look into how this could be
done with a Python script instead of DTML, but this version of our
product is all DTML, so that's why I'm using this solution for now.
Next version we're moving to Zope 3, so things should get better!
In any case, Jonathan's solution worked (though he had single quotes
around 'calstart' which shouldn't have been there.) What I'm doing
is setting up a hash table so I can do some branching in a separate
loop. I have a feeling I'm building a hash table for something I may
be able to access directly, but it's working, so I don't want to take
up more space in peoples' inboxes. Thanks again for the quick help!
-Andrew
On Feb 27, 2006, at 10:15 AM, Andreas Pakulat wrote:
On 27.02.06 09:56:49, Andrew Hedges wrote:
Allow me to preface this by saying I am a complete newbie to Zope
(I prefer to
think of it as beginner's mind...). What I am attempting to do is
dynamically
add items to a dictionary, but Zope complains keyword can't be an
expression.
Here's the reduced case of my code:
dtml-let eventsDict={}
dtml-let calstart=somestring
dtml-call REQUEST.set(eventsDict[calstart]=id)
/dtml-let
/dtml-let
First let me tell you: Write a python script for things like this, it
really belongs into one.
Second thing: your dtml-call has a serious error, eventsDict[..]=id is
executed but it doesn't produce anything so set is called with no
parameters and this is wrong. set needs 2 parameters, one beeing a
string as the key and a second as the value which can be of any type
python knows.
I also don't get what this snippet should do?
Andreas
___
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] Dynamic dictionary keys?
- Original Message -
From: Andrew Hedges [EMAIL PROTECTED]
To: Jonathan [EMAIL PROTECTED]
Sent: Monday, February 27, 2006 12:14 PM
Subject: Re: [Zope] Dynamic dictionary keys?
Thanks, much, Jonathan! We're moving to Zope 3 on the next version of
our software, but what I'm working on is part of the last version, which
is all DTML. I appreciate your response! It works, though, there was a
small error in what you sent:
dtml-call eventsDict.update({calstart:id})
There are various forms, all of which are correct, and it depends upon what
you are trying to achieve:
dtml-call eventsDict.update({calstart:id})
The above format takes two variables, one called calstart and one called id.
The value contained within the variable calstart is used as the 'key' and
the contents of id are used as the 'value'
dtml-call eventsDict.update({'calstart':id})
The above format takes one 'hard-coded' key value 'calstart' and one
variable id for the value
dtml-call eventsDict.update({'calstart':'id'})
The above format takes a 'hard-coded' key value 'calstart' and a hard-coded
value 'id'.
None of the above are 'wrong', it just a matter of what you are trying to
accomplish.
Jonathan
Thanks, again!
-Andrew
On Feb 27, 2006, at 10:05 AM, Jonathan wrote:
- Original Message - From: Andrew Hedges
[EMAIL PROTECTED]
To: zope@zope.org
Sent: Monday, February 27, 2006 11:56 AM
Subject: [Zope] Dynamic dictionary keys?
Allow me to preface this by saying I am a complete newbie to Zope (I
prefer to think of it as beginner's mind...). What I am attempting to
do is dynamically add items to a dictionary, but Zope complains
keyword can't be an expression. Here's the reduced case of my code:
dtml-let eventsDict={}
dtml-let calstart=somestring
dtml-call REQUEST.set(eventsDict[calstart]=id)
/dtml-let
/dtml-let
It is much easier in python script, but if you really want to use dtml:
dtml-call REQUEST.set('eventsDict', {})
dtml-call eventsDict.update({'calstart' : id})
hth
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 )
Re: [Zope] Dynamic dictionary keys?
On 2/27/06, Andrew Hedges [EMAIL PROTECTED] wrote: Allow me to preface this by saying I am a complete newbie to Zope (I prefer to think of it as beginner's mind...). Welcome! And let's start with killing off two ideas that most newbies have (because the documentation gives it to the,): 1. Through-the-web development really isn't such a hot idea. :-) Granted, it has it's uses, but most of the time it's a pain in the ass, because: a. By necessity, the extra security needed means you have restrictions that are hard to circumvent. b. It's really hard to have verisoning and making diffs on things that reside in a ZODB. c. A text field in a browser isn't the most programmer friendly editor you can imagine. It is therefore quite likely you want to start making disk-bsed products quite quick. See http://zopewiki.org/DiskBasedProduct Since TTW development was one of the original ideas with Zope, the documentation is very focused on it, but most people notice that it's actually quicker and easier to go the disk-based way. YMMV and so forth. 2. Doing things in the template is not a good idea. As mentioned above, you want to do any kind of logic in python. That means either in a disk-based product, or in a Python-script. The Zope documentation doesn't say this clearly enough. In fact, it often encourages you to do complicated things in DTML. Besides, ZPT is a new and better templating language, you might want to use that instead of DTML. It's largely a matter of taste, I definitely prefer ZPT, but as long as you keep *all* logic from the template it becomes less important. See also: http://blogs.nuxeo.com/sections/blogs/lennart_regebro/2005_04_19_python_statement -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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 )
[Zope] product security changes from 2.8 to 2.8.5 ?
Hello
I recently moved my zope product developed on a 2.8 server on to a 2.8.5
server, and all of my python code is no longer being published out.
In the past I had been using a doc string doc to make methods
accessible. I realize this is not the proper procedure, but it worked.
Now, on the 2.8.5 server, all of these are refused.
I've been going through and doing security.declarePublic('methodname')
on everything I want to be public, but it does not appear to have any
effect.
Are there any other changes that I need to make to my product in order
to get back the functionality I had previously?
Am I even looking in the right place?
Thanks for any tips
-e-
___
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] product security changes from 2.8 to 2.8.5 ?
--On 27. Februar 2006 15:20:11 -0800 Ed Colmar [EMAIL PROTECTED] wrote:
Hello
I recently moved my zope product developed on a 2.8 server on to a 2.8.5
server, and all of my python code is no longer being published out.
In the past I had been using a doc string doc to make methods
accessible. I realize this is not the proper procedure, but it worked.
Now, on the 2.8.5 server, all of these are refused.
I've been going through and doing security.declarePublic('methodname') on
everything I want to be public, but it does not appear to have any effect.
Are there any other changes that I need to make to my product in order to
get back the functionality I had previously?
Do you call InitializeClass()?
Perhaps VerboseSecurity might help you.
-aj
pgpvwlND0jIHm.pgp
Description: PGP signature
___
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] product security changes from 2.8 to 2.8.5 ?
Hey Andreas, thanks for the reply.
I have Globals.InitializeClass(classname) at the end of my product code
(outside the class)
I turned on Verbose Security, but hmm... maybe this is not a security
issue after all.
I have code that worked within my product before like:
def send_password_reminder(self, email):
blah
Now I see get a name error when trying to access it.
*Error Type: NameError*
*Error Value: name 'send_password_reminder' is not defined
I thought it was a security problem... Is this related to something else?
Thanks again!
-e-
*Andreas Jung wrote:
--On 27. Februar 2006 15:20:11 -0800 Ed Colmar [EMAIL PROTECTED]
wrote:
Hello
I recently moved my zope product developed on a 2.8 server on to a 2.8.5
server, and all of my python code is no longer being published out.
In the past I had been using a doc string doc to make methods
accessible. I realize this is not the proper procedure, but it worked.
Now, on the 2.8.5 server, all of these are refused.
I've been going through and doing
security.declarePublic('methodname') on
everything I want to be public, but it does not appear to have any
effect.
Are there any other changes that I need to make to my product in
order to
get back the functionality I had previously?
Do you call InitializeClass()?
Perhaps VerboseSecurity might help you.
-aj
___
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] Dynamic dictionary keys?
Hi Andrew
Allow me to preface this by saying I am a complete newbie to Zope
In that case, please skip DTML and go straight to ZPT. DTML is like
the ghost train in an amusement park, but the ghosts are real. Especially
if you're a newbie.
dtml-let eventsDict={}
dtml-let calstart=somestring
dtml-call REQUEST.set(eventsDict[calstart]=id)
/dtml-let
/dtml-let
Don't code python in a template. Call a Python Script which prepares
your dictionary instead. E.g.
ul tal:define=eventsDict here/getEvents.../ul
--
jean
___
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] Packing data.fs programmatically
Ron Bickers wrote: What's the solution without ZEO and without having to stop Zope? You use ZEO. Get over it, it should be how a standard Zope instance is set up, IMNSHO... So, in other words, there isn't one. I take it you're a big fan of ZEO. ;-) I guess I'll check it out. I've been using Zope for 7-ish years and just never bothered. Well exactly. ZEO is not only for scaling Zope to multiple app serving clients, it's the way that ZODB allows multiple processes to access a single database. Think of it in the same way as you'd thing of something like MySQLDB, psycopg or DCOracle2... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] webdav and PUT_factory
Luca Dall'Olio wrote: According to my past experience in java, this means cvs ^_^ For the rest of us, it means svn ;-) Should I stop using the ZMI? Probably. At the very least, take advantage of the webdav you seem to have already got working and use a normal text editor for editing your scripts and templates! Should I develop a Zope Product instead? Probably ;-) Should I use fsdump instead of webdav to export from zope ? No.. Should I use webdav when deploying back to Zope? Not unless you're doing all your editing via WebDAV... We develop inside locally installed Zope Instances, using the ZMI. Eep, at least get a text editor going over webdav so you don't have to use a browser to edit your scripts and methods! At the end of the day, we export the work done using webdav, and this works for DTML documents, DTML methods and ZSQL methods. Okay, stop using DTML documents and methods. Use python scripts and ZPT, please god! ;-) After that, we commit inside the source code repository, using the update, diff and merge features to synchronize with other developers' work. Odd... We need to deploy to a Zope server in order to test the integration of developers' code, so I wrote a little PUT_factory to re-create the right objects, this is a snippet: elif ext == 'zsql': from Products.ZSQLMethods.SQL import SQL return SQL(name, '', 'daticonvegno', '' ,'') elif ext == 'dtml': from OFS.DTMLDocument import DTMLDocument return DTMLDocument( '', __name__=name ) elif ext == 'dtmm': from OFS.DTMLMethod import DTMLMethod return DTMLMethod( '', __name__=name ) elif major == 'text': from OFS.DTMLDocument import DTMLDocument return OFS.DTMLDocument.DTMLDocument( '', __name__=name ) Fair enough... 1) you have to use extensions to make it work, otherwise you will have trouble at deploy-time Yup, but extensions are pretty handy ;-) 2) some additional parameters such as the connectionIds for ZSQLMethods must be auto-magically chosen by the PUT_factory Oh, yes, that's silly ;-) 3) what about more complex objects, such as Plone, Archetypes or Openflow? should I map them all in the PUT_factory? Ah, so you're using Plohn. Well, then you should put all you code in Filesystem Directory Views, it'll make it all _much_ easier for you! You can then look to GenericSetup to handle all your workflow configs, etc... Is this the right way to do things in Zope? Nope, not given the products you're using... Is there any native solution for Source Code Versioning and Team Management? Not really, the History tab is as close as it gets... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
[Zope] Squishdot on Zope 2.9.X with Python 2.4.2
Are there any known compatibilty problems? -d -- ___ 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 )
[Zope-DB] More cache key errors?
Hi Michael, Michael Mauws wrote: Not sure how much this is going to help, Chris, but I can tell you that, after upgrading to V2.8 (from V2.3 or thereabouts), Wow, that's a big jump! I found that I was getting key errors that displayed the entire SQL statement on any of my ZSQL methods that made use of the caching function. Okay, was the error coming from the same line as the code I pasted? After setting the cache time to zero seconds, the errors ceased. Yes, but then you're getting no caching... in high load scenarios that's a bad thing! cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
