Re: [Zope-CMF] [dev] i18n Message objects: encoding issues
yuppie wrote: 2.) Switch completely to unicode in CMF 2.0: Sounds like a too big change, don't think we should try that. I think we all know this is where we need to be eventually, 2.0 seems the right time to do that, I'd actually prefer this, even though it'll delay the 2.0 release... 3.) Use encoded strings and unicode side by side: This requires to know the encoding of the encoded strings. 'default_charset' should provide that information. arrrgg there be dragons... 3.1.) Encode unicode strings before passing them to page templates: The unicode strings are only returned by newly added parts of the code. So it might be easier to find all the places where a conversion is necessary. On the other hand Message objects are also unicode, so we would have to translate them before passing them to the templates. Yeah, okay, it'll work, but it sucks long term as it's even mroe code that needs to be undone when CMF goes fully unicode... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup doc
Hi Tres! Hi Florent! Tres Seaver wrote: Florent Guillaume wrote: Here is some doc I wrote about GenericSetup: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2006_01_24_genericsetup-for-cps-cmf A very nice writeup. Could we get it (or the non CPS-specific bits) added to docs for GenericSetup? I just added a 'doc' directory and checked in the fragments of documentation I had in my sandbox. Everybody is welcome to change and improve those docs. Florent's writeup would be indeed a valuable contribution. BTW: In which checkin list do GenericSetup checkins show up now? A couple of points: - The selective export think *used* to work; I didn't know it was broken. I used it frequently in the project which spawned the move from CMFSetup to GenericSetup. Florent writes about *incremental* exports, not about *selective* exports. Selecting specific export steps should still work. - The upgrade feature you talk about for CPS sounds a bit like what the version attribute was originally for on import steps: in the original implementation, the tool knew what versions of import steps had been run in the past, and you could see which steps were newer (or had never been run) on the import view. I don't know where that feature went. It seems as though we should either add your update feature, or else resurrect the version UI (or maybe both?) I have to admit that I never understood why import steps have a version attribute. And I still don't understand that concept: Does that mean each upgrade needs its own import steps? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: GenericSetup doc
On 25 Jan 2006, at 10:42, yuppie wrote: BTW: In which checkin list do GenericSetup checkins show up now? Hi Yvo, They show up in the generic zope checkins list, where all the Zope checkins themselves go. This can be changed to point at another list (or additional lists), but there would be drawbacks. Sending them to the CMF list would mean people who want to use it outside of the CMF would have to subscribe to the CMF list. Sending them to the generic list and the CMF list would mean duplicates for a lot of people. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup doc
Hi Tres! Hi Florent! Tres Seaver wrote: Florent Guillaume wrote: Here is some doc I wrote about GenericSetup: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2006_01_24_genericsetup-for-cps-cmf A very nice writeup. Could we get it (or the non CPS-specific bits) added to docs for GenericSetup? I just added a 'doc' directory and checked in the fragments of documentation I had in my sandbox. Everybody is welcome to change and improve those docs. Florent's writeup would be indeed a valuable contribution. BTW: In which checkin list do GenericSetup checkins show up now? http://mail.zope.org/mailman/listinfo/zope-cvs A couple of points: - The selective export think *used* to work; I didn't know it was broken. I used it frequently in the project which spawned the move from CMFSetup to GenericSetup. Florent writes about *incremental* exports, not about *selective* exports. Selecting specific export steps should still work. Ah, OK. I was confused by the which XML files phrase. - The upgrade feature you talk about for CPS sounds a bit like what the version attribute was originally for on import steps: in the original implementation, the tool knew what versions of import steps had been run in the past, and you could see which steps were newer (or had never been run) on the import view. I don't know where that feature went. It seems as though we should either add your update feature, or else resurrect the version UI (or maybe both?) I have to admit that I never understood why import steps have a version attribute. And I still don't understand that concept: Does that mean each upgrade needs its own import steps? The use case was that, over time, an import step might be updated. If you had installed your site before the update, then your configuration might also need to be updated. Some version of the setup tool (maybe never publicly released) tracked the 'version' last installed for each step, and would show you the steps which were out-of-date, or had never been installed, in a way which made them easy to distinguish. I think there was a convenience button which ran only such steps, as well. Tres. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] FS Skins and Last-Modified
Hello,
I have several FS based skins that use DTML ... I've been controlling
caching through the usual:
dtml-call RESPONSE.setHeader('Content-Type','text/css')
dtml-call RESPONSE.setHeader('Expires', _.DateTime(_.DateTime().timeTime()
+ 3600).toZone('GMT').rfc822())
dtml-call RESPONSE.setHeader('Last-Modified',
bobobase_modification_time().toZone('GMT').rfc822())
This has worked well for me for some time now ...
But, for some reason, now it seems bobobase_modification_time comes out
wrong :(
It's stuck at some date in October, even though the files are far more
recent. This is causing problems with web browsers that have stale code
when they shouldn't, breaks my AJAX interfaces, etc ...
I saw FSObject has getModTime(), but I can't seem to call it from anywhere?
I tried in the header, or in a separate Python Script, to no avail.
So for now, clients are still being told that their months old .js file has
not been modified, even though it has :( (Which is causing me nightmares)
Any know what's going on? A quick fix? A better idea? Any help would be
greatly appreciated!
(This is Zope 2.7.4 with CMF 1.5.0 running on ZEO, I'm working on a major
rewrite with much more up to date versions ...)
Jean-François Doyon
Internet Service Development and Systems Support / Spécialiste de
dèveloppements internet et soutien technique
Canada Centre for Remote Sensing/Centre Canadien de télédétection
Natural Resources Canada/Ressources Naturelles Canada
http://atlas.gc.ca
Tel./Tél.: (613) 992-4902
Fax: (613) 947-2410
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
