[Zope3-dev] [EMAIL PROTECTED]: [Zope3-checkins] SVN: Zope3/trunk/src/zope/app/file/ file an image views now set the Last-Modified header and handle If-Modified-Since if the context is adaptable to IZo
After looking at this checkin, and related to my experiments with
python and gnome-vfs [1], I'm left wondering if Zope shouldn't have a
interface that specifies a structure similar to what a os.stat() call
returns.
That would make the overhead of implementing stuff that needs only
creation/modification time or stuff related to filesystems etc much
easier.
[1] http://awkly.org/archive/nautilus-plone-backend
--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
---BeginMessage---
Log message for revision 67711:
file an image views now set the Last-Modified header and handle
If-Modified-Since if the context is adaptable to IZopeDublinCore. This adds a
dependency to zope.dublincore.
Changed:
U Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg
U Zope3/trunk/src/zope/app/file/browser/file.py
U Zope3/trunk/src/zope/app/file/browser/file.txt
U Zope3/trunk/src/zope/app/file/browser/image.py
-=-
Modified: Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg
===
--- Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg 2006-04-28 10:45:24 UTC
(rev 67710)
+++ Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg 2006-04-28 11:01:55 UTC
(rev 67711)
@@ -7,3 +7,4 @@
zope.publisher
zope.schema
zope.testing
+zope.dublincore
Modified: Zope3/trunk/src/zope/app/file/browser/file.py
===
--- Zope3/trunk/src/zope/app/file/browser/file.py 2006-04-28 10:45:24 UTC
(rev 67710)
+++ Zope3/trunk/src/zope/app/file/browser/file.py 2006-04-28 11:01:55 UTC
(rev 67711)
@@ -15,8 +15,6 @@
$Id$
-from datetime import datetime
-
import zope.event
from zope import lifecycleevent
from zope.contenttype import guess_content_type
@@ -27,21 +25,101 @@
from zope.app.file.file import File
from zope.app.file.interfaces import IFile
from zope.app.i18n import ZopeMessageFactory as _
+from zope.dublincore.interfaces import IZopeDublinCore
+import zope.datetime
+import time
+from datetime import datetime
+
__docformat__ = 'restructuredtext'
-
class FileView(object):
def show(self):
-Call the File
-request = self.request
-if request is not None:
-request.response.setHeader('Content-Type',
- self.context.contentType)
-request.response.setHeader('Content-Length',
- self.context.getSize())
+Sets various headers if the request is present and returns the
+data of the file. If the If-Modified-Since header is set and
+the context implements IZopeDublinCore, data is only returned if
+the modification date of the context is new than the date in the
+If-Modified-Since header
+ from zope.publisher.browser import BrowserView, TestRequest
+ class FileTestView(FileView, BrowserView): pass
+ import pytz
+ class MyFile(object):
+... contentType='text/plain'
+... data=data of file
+... modified = datetime(2006,1,1,tzinfo=pytz.utc)
+... def getSize(self):
+... return len(self.data)
+
+ aFile = MyFile()
+ request = TestRequest()
+ view = FileTestView(aFile,request)
+ view.show()
+'data of file'
+ request.response.getHeader('Content-Type')
+'text/plain'
+ request.response.getHeader('Content-Length')
+'12'
+
+If the file is adaptable to IZopeDublinCore the
+Last-Modified header is also set.
+
+ request.response.getHeader('Last-Modified') is None
+True
+
+For the test we just declare that our file provides
+IZopeDublinCore
+ from zope.interface import directlyProvides
+ directlyProvides(aFile,IZopeDublinCore)
+ request = TestRequest()
+ view = FileTestView(aFile,request)
+ view.show()
+'data of file'
+ datetime.fromtimestamp(zope.datetime.time(
+... request.response.getHeader('Last-Modified')))
+datetime.datetime(2006, 1, 1, 0, 0)
+
+If the If-Modified-Since header is set and is newer a 304
+status is returned and the value is empty.
+
+ modified = datetime.now()
+ modHeader =
zope.datetime.rfc1123_date(time.mktime(modified.timetuple()))
+ request = TestRequest(IF_MODIFIED_SINCE=modHeader)
+
+ view = FileTestView(aFile,request)
+ view.show()
+''
+ request.response.getStatus()
+304
+
+
+
+if self.request is not None:
+self.request.response.setHeader('Content-Type',
+self.context.contentType)
+self.request.response.setHeader('Content-Length',
+
Re: [Zope3-dev] Heads up: I'm about to merge the jim-adapter branch
Jim Fulton wrote: I'm about to merge the jim-adapter branch. This branch has three major refactorings on it: - A redesign of the adapter registration machinery Hey, just some feedback and kudos to you, Jim. Component registration is now indeed a lot more simple, and more flexible. The ability to have a utility managed in content space is very useful, for instance. One pitfall for people is that just registering a utility is not enough - utilities that were in the site management folder before still need to be placed somewhere now of course, as they tend to rely on being located (for instance authentication utilities look up the next utility). Is it possible to have completely non-persistent local utilities in the new world? Thanks! Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Heads up: I'm about to merge the jim-adapter branch
Martijn Faassen wrote: Jim Fulton wrote: I'm about to merge the jim-adapter branch. This branch has three major refactorings on it: - A redesign of the adapter registration machinery Hey, just some feedback and kudos to you, Jim. Component registration is now indeed a lot more simple, and more flexible. The ability to have a utility managed in content space is very useful, for instance. One pitfall for people is that just registering a utility is not enough - utilities that were in the site management folder before still need to be placed somewhere now of course, as they tend to rely on being located (for instance authentication utilities look up the next utility). Is it possible to have completely non-persistent local utilities in the new world? Not entirely sure what you mean ny non-persistent. Assuming that you mean not stored in the database, then yes, by creating a non-persistent component registry and making it a site manager or making it a base of a persistent site manager. 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope-3.2.1.tgz Zope version
Hello, Zope-3.2.1.tgz does not have the version.txt in src/zope/app, so Zope version is set to Development/Unknown in zopeversion.py. Though I think that it is not so serious problem, we should update the tar ball or leave it? -- Yoshito Komatsu [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope-3.2.1.tgz Zope version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshito Komatsu wrote: Hello, Zope-3.2.1.tgz does not have the version.txt in src/zope/app, so Zope version is set to Development/Unknown in zopeversion.py. Though I think that it is not so serious problem, we should update the tar ball or leave it? Leave it. If need be, we could release a 3.2.1.1 with the fix. If we replace it, people have no way of knowing whether the version they got has the fix or not, without peeking inside the tarball itself. This is a general release management principle: we have been guilty of violating it several times in tha past. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEUkbJ+gerLs4ltQ4RAtHfAJ4jsQ7fkuBtcyhc7fHuAqmGKnNHmwCfQItd nyXvyLvuQslx88GhhudHm/I= =neWA -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Automatic translation of message id's is deprecated and will be removed in 3.3
Martijn proposed this be undeprecated (http://mail.zope.org/pipermail/ zope3-dev/2005-December/016781.html) and others agreed, at least in part. AIUI, Martijn ended up not making any changes in Zope 3, but somehow changing Zope 2 in such a way as to work around his issue. The deprecation certainly is a pain for those of us who have one template replacement that sometimes may be user entered (non-message ids) and sometimes may be automatically generated (message ids). Also, 3.3 is upon us, and the deprecation message claims that the behavior will be gone in this release. I would have time for simply removing the deprecation, not changing the behavior in any way. What's the consensus? Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope-3.2.1.tgz Zope version
Hello, Thank you for replying. Tres Seaver wrote: Zope-3.2.1.tgz does not have the version.txt in src/zope/app, so Zope version is set to Development/Unknown in zopeversion.py. Though I think that it is not so serious problem, we should update the tar ball or leave it? Leave it. If need be, we could release a 3.2.1.1 with the fix. If we replace it, people have no way of knowing whether the version they got has the fix or not, without peeking inside the tarball itself. This is a general release management principle: we have been guilty of violating it several times in tha past. I understand. Regards, -- Yoshito Komatsu [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
