RE: [Zope] Updating object's modification timestamp?
So in order trigger a "modification" I actually have to go modify a dummy property? Okay. For now I'll "touch" pages by calling manage_changeProperties() on some dummy property, but in the long run this isn't good enough. I suggest adding a touch() method that lets you update the time stamp programmatically. Why? Well, in my case I have a front page which uses an SQL database for news, articles, and various things. Whenever an editor posts an article (through a Zope-built management interface), the front page should be "touched"; otherwise Zope will give the wrong Last-Modified date to the browser, and all users will see is the old page. Of course, I could just succumb to a fit of laziness and set Cache-Control: no-cache and forget all about it, but I think caching is a good thing. -- Alexander Staubo http://www.mop.no/~alex/ "It has taken the planet Earth 4.5 billion years to discover it is 4.5 billion years old." --George Wald
-----Original Message----- From: Brian Lloyd [mailto:Brian@digicool.com] Sent: 22. juni 1999 18:23 To: 'Alexander Staubo'; Zope Mailing List (E-mail) Subject: RE: [Zope] Updating object's modification timestamp?
Is there any way of updating an object's modification timestamp (_p_mtime or bobobase_modification_time(), from what I gather from the sources) programmatically through Python? How?
Sure - just modify the object ;) The modification time reflects the last time the object was actually modified in the db, and is _depended on_ by the database, so you should not try to modify it yourself...
Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
In article <B059671903C6D211A0D500C0F0301C7910C8FF@kubrick.mop.no>, Alexander Staubo <alex@mop.no> writes
I suggest adding a touch() method that lets you update the time stamp programmatically. Why? Well, in my case I have a front page which uses an SQL database for news, articles, and various things. Whenever an editor posts an article (through a Zope-built management interface), the front page should be "touched"; otherwise Zope will give the wrong Last-Modified date to the browser, and all users will see is the old
Are you saying that Zope sends the last-modified date to the browser based on the actual modification date of the dtml page? If so, it seems to me that Zope should have it's own time stamp which it uses for its own internal processes, and you should have an option of either using that date for last-modified, or for using a user defined variable. ------- Regards, Graham Chiu gchiu<at>compkarori.co.nz
At 18:36 22/06/99 , Alexander Staubo wrote:
So in order trigger a "modification" I actually have to go modify a dummy property? Okay. For now I'll "touch" pages by calling manage_changeProperties() on some dummy property, but in the long run this isn't good enough.
I suggest adding a touch() method that lets you update the time stamp programmatically. Why? Well, in my case I have a front page which uses an SQL database for news, articles, and various things. Whenever an editor posts an article (through a Zope-built management interface), the front page should be "touched"; otherwise Zope will give the wrong Last-Modified date to the browser, and all users will see is the old page. Of course, I could just succumb to a fit of laziness and set Cache-Control: no-cache and forget all about it, but I think caching is a good thing.
A better option would be to send DC a patch where you move the setting of the last-modified header to _before_ rendering the DTML, so it can be overridden in that DTML. Or so that it at least checks wether the DTML has set a last-modified header and leaves it intact. That way you can programmatically change the last-modified header sent to the browser. Much better solution. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
participants (3)
-
Alexander Staubo -
Graham Chiu -
Martijn Pieters