[Zope-dev] State of ZPatterns
Itai wrote: > My understanding was, though, > that TransWarp will replace ZPatterns as the best tool for object > model based development, which means that the idea of developing > ZPatterns code with a view for long term future reuse suddenly isn't > that attractive. My inclination exactly. I would feel so much better if all these geniuses would just jump "straight to Go". It seems, though, that they have to work through this "unproductive" prototyping stage in order to get there. Of course, I can't complain, since just watching the breakneck evolution of Python, Zope, ZPatterns, and all the amazing goodies that show up here and at Zope.org leave my head spinning. If I recall, the original RIPP slide presentation stated pretty clearly that the toolkit that came to be called ZPatterns was really just the groundwork needed to achieve a much larger goal. So, TransWarp is that much closer to reality, and it took ZPatterns to make that happen. The stamina alone is mind boggling, let alone the fact that useful stuff, _very_useful_stuff_, was generated along the way. also: > I expect the ZPatterns-based e-commerce app > I'm building today to make the e-commerce app I build in 12 months a > lot easier to build. So any changes in the basic tools I use bother > me. Me too. My preference is to have only the best solutions right from the start, and to only have to learn things once. Problem is, after 14 years doing this stuff, none of it has had the simple courtesy to just stand still! The good news is, for the most part, the trend is in the general direction of improvement. Again, how can I complain? I don't pretend to fully "get" any of the stuff these guys, nor the DC crew, not to mention the PythonLabs team, and all the astounding folks on the lists are cooking up for the rest of us. All that I can say for certain is that based on past history, it will be even more amazing than the stuff that has me totally dazzled already. One thing that has definitely grabbed my attention about TransWarp is the goal of not only making Zope development more flexible and powerful, but to bring the same facility to "Extra-Zope" development. We all hang out here because of the incomparable degree to which Zope has empowered Web development. But Jim Fulton himself has said how tickled he is that folks are starting to use ZODB independent of Zope. Zope is, after all, an amalgam of several Python modules, any one of which can be pulled into a non-Zope application. Right now, at this point in time, the Web is absolutely critical, and anything that helps us deal with the crude state of the Web (e.g. browser hell) is a life-saver. So, Zope's greatest strength is its Web-centricity, but it can also be it's Achille's heal, once the Web reaches maturity, and technology moves on. Something like TransWarp can assure that all the goodies that we build for Zope can continue to live on and remain viable, long after "The Web" is a quaint artifact, a footnote in the primitive history of an ubiquitous Global Communication System. Thanks Phil, Ty, Jim, Brian, Paul, Shane, Tres, Michel, Amos, Guido, Tim, Ken, and way too many more to mention! Jerry S. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] SAP DB <--> ZODB ?
Kapil said: > looks like it will instantly become the most advanced open source database > out there. my current rankings of the general os rdbms in terms of features > postgresql->interbase->mysql Keep in mind that (even though) it is an effective "general os rdbms", PostgreSQL was originally developed as an experimantal platform for testing concepts in the Object-Relational database realm. As such, it has some unique potential, especially in its ability to define and store Objects as _native_data_types_. Most of the effort and press related to PostgreSQL in the recent past has focused on adding SQL in place PostgreSQL's QEL, and improving stability and performance. Now that most of this important work has been accomplished, my hope is that some of the truly differentiating features can be showcased, e.g. a Zope Storage where an external SQL engine can directly interact with objects as native data. Imagine a SQL statement that updates every instance of a ZClass with new properties, or slipping a super-class in underneath (re-parenting), where it had never been before. also: > the feature list of this database is astonishing > www.sapdb.org > > to name a few > subtransactions > outer joins > sql 92 compliant, possible modes for db2, oracle 7 > very nice prodecural sql language. > lots of statistics information > really rich set of standard functions > scrollable cursors > > this is a great candidate for a zodb storage SAP DB is a fully licensed version of Software AG's (SAG) Adabas D, a descendant of SAG's venerable mainframe class system, Adabas C. Yes, SQL is fully supported, but SQL is after all a query language, not a physical model of the internal structure of an rdbms. This is not to say that Adabas, in any form, is any less of a capable system. Don't be surprised, however, to find something much closer to a network database under the surface, compared to PostgreSQL, which is about two generations newer, according to its "birth date" (1988?). Interestingly, many folks who have been around for several "database revolutions" see the network model as a very good choice for storage of "non-tabular" data types, such as objects, etc. On the other hand, that may be the result of lack of familiarity with the possibilities inherent in a true Object-Relational data model. Later, Jerry S. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Hi Fred, I read the serialization proposal... yours is somewhere inbetween what we have now and where I think we're heading. I really like the format of your proposals! These should definitely go up on the fishbowl. One thing that I think is important for a FS serialization strategy is that the filesystem representation of objects should be as simple as possible to work with. This means that the filesystem representation of a PythonScript should look like a Python script, that the filesystem representation of a DTML method should look as much as possible like a normal HTML document, etc. Instead of relying on a single monolithic format for fs reps of Zope objects (e.g. one expressed in XML), I think each object should be able to determine its own serialization to filesystem. Properties and security settings of each object could be expressed in the contents of a separate file (e.g. a "resource fork" in Mac terminology, I guess) which would be related to the actual content via a naming convention. Tres Seaver has done some work on this with his FSDump product (http://www.zope.org/Members/tseaver/FSDump), although it only goes "one way" at the moment, and Steve Spicklemire has gone a slightly different route with his ZCVSMixin product (http://www.zope.org/Members/sspickle/ZCVSMixin/). I have a proposal up on the Digital Creations intranet which makes the proposal to leave serialization format up to each object, and gives some info about possible implementation strategies. I need to clean it up and move it over to the fishbowl at some point, but I hope this email serves as a sort of overview about what we want to do about the problem at DC... it'd be great to be able to conserve resources and work on the same problem together. - Original Message - From: "Fred Wilson Horch" <[EMAIL PROTECTED]> To: "Chris McDonough" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, March 11, 2001 11:30 PM Subject: Re: [Zope-dev] FTP interface being worked on? > Hi Chris, > > You wrote in part: > > > > The "export as files" paradigm is something we'd really like to see soon in > > Zope. [...] I'd be interested in seeing your proposal too. > > Great to hear we're thinking alike. My proposals are available on our > SourceForge site (sorry for the long URL -- I can send the proposals as > an attachment if you'd prefer): > > FTP proposal > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/ftp_access/ftp_acces s_prop.txt?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=ecoaccess > > XML-RPC proposal (export as files) > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/xml_rpc/xml_rpc_prop .txt?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=ecoaccess > > > The best place for these sorts of things are at http://dev.zope.org (the > > "fishbowl")... > > Okay, I'll take a look and submit my proposals through the Fishbowl > process. > > Thanks, > Fred > > -- > Fred Wilson Horch mailto:[EMAIL PROTECTED] > Executive Director, EcoAccess http://ecoaccess.org/ > P.O. Box 2823, Durham, NC 27715-2823 phone: 919.419-8354 > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Hi Chris, You wrote in part: > > The "export as files" paradigm is something we'd really like to see soon in > Zope. [...] I'd be interested in seeing your proposal too. Great to hear we're thinking alike. My proposals are available on our SourceForge site (sorry for the long URL -- I can send the proposals as an attachment if you'd prefer): FTP proposal http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/ftp_access/ftp_access_prop.txt?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=ecoaccess XML-RPC proposal (export as files) http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/xml_rpc/xml_rpc_prop.txt?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=ecoaccess > The best place for these sorts of things are at http://dev.zope.org (the > "fishbowl")... Okay, I'll take a look and submit my proposals through the Fishbowl process. Thanks, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Ensuring 'freshness' of dynamic pages (slightly offtopic)
"Morten W. Petersen" wrote: > Is it possible to ensure that pages are always fresh, even if it is > specified on the client side that the client should never try to > retrieve a 'fresher' page? Send an "expiration" header with a valid date that has already passed. This has always worked for me, even in old browsers. Please tell me this still works. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Ensuring 'freshness' of dynamic pages (slightly offtopic)
"Morten W. Petersen" wrote: > Is it possible to ensure that pages are always fresh, even if it is > specified on the client side that the client should never try to > retrieve a 'fresher' page? Send an "expiration" header with a valid date that has already passed. This has always worked for me, even in old browsers. Please tell me this still works. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Hi Fred, The "export as files" paradigm is something we'd really like to see soon in Zope. We'd like it to be possible for objects to be asked for a "filesystem representation" of themselves and serialize their structures out to disk. This filesystem representation should be simple enough to edit naturally for all kinds of files, and it should play nicely with tools like CVS. I have a proposal up somewhere about this, which basically claims that objects should decide on their own representations of themselves, and that two-way "sync" should be accomplishable. I'd be interested in seeing your proposal too. The best place for these sorts of things are at http://dev.zope.org (the "fishbowl")... Thanks! - C - Original Message - From: "Fred Wilson Horch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, March 11, 2001 5:57 PM Subject: [Zope-dev] FTP interface being worked on? > Hi folks, > > Is anyone working on the FTP support in Zope? For our project, we'd > like to improve the FTP interface to Zope. > > I noticed that ZServer/README.txt in Zope 2.3.1b1 states > > Properties and FTP: The next step > > The next phase of FTP support will allow you to edit properties of > all Zope objects. Probably properties will be exposed via special > files which will contain an XML representation of the object's > properties. You could then download the file, edit the XML and > upload it to change the object's properties. > > We do not currently have a target date for FTP property support. > > I have a proposal written up, if anyone is interested in providing > feedback to me before I start work on it. > > Along these lines, I also have a proposal to add an export / import > feature that would dump objects in the ZODB to separate files in a > directory tree. (Currently the XML export seems to create one big XML > file.) The goal is to allow objects to be managed as flat files so you > can edit them more easily and use CVS to track revisions. > > Also, it sure is confusing to try to figure out where you accept > patches. Is the Collector still the best place to send them? > > Thanks, > Fred > -- > Fred Wilson Horch mailto:[EMAIL PROTECTED] > Executive Director, EcoAccess http://ecoaccess.org/ > P.O. Box 2823, Durham, NC 27715-2823 phone: 919.419-8354 > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Designing ZPatterns/Python-product-based, reusable applications - take 2
Phillip J. Eby wrote: >At 10:24 AM 3/11/01 +1100, Itai Tavor wrote: >> >>Then I need Specialists to manage collections of PD classes. I think >>that these would also benefit from being product-based, so I subclass >>Specialist to create a manager for each role in the application. Now, >>since an existing application might be expanded, the Specialists all >>need factory methods and will all show up in Zope's Add New Object >>menu. > >Or you may want to just create one factory method that creates an entire >family of related Specialists. Specialists do support TTW overriding of >their methods, if you set up the methods properly in your Python code. (I >forget how this works, though, you'll probably need to check the source code.) The reason I think I need factory methods for all Specialists is that it would enable adding features to an existing site - so it would support multiphase development. About TTW overriding of Specialist methods - didn't even think to look for such an option. I'll check the code. It could be very useful. > >- Many of the classes will also have web user UI, and since this has >>to be designed to fit the design of the web site in which the >>application is used, the UI methods will have to be located where >>designers can modify them - in the ZODB. For the Specialists, I can >>install a default set of UI methods when an instance of the >>Specialist is installed. But where do I store PD class UI methods? >>EMarket's solution is to store them in the Specialist, but this not >>only breaks O-O rules, it can also be very ugly. Say I have a >>Specialist managing 3 PD classes. Instead of an index_html method for >>each class, I'll need class1index_html, class2index_html, >>class3index_html in the Specialist. And each class would have to >>define: >> >> def index_html(self, REQUEST, RESPONSE, **kw): >> return self.class1index_html(REQUEST, RESPONSE, kw) >> >>This is unacceptably ugly. But the only other thing I can think of >>doing is creating a ZClass for each PD class and store the UI methods >>there. But that's also pretty unacceptable. Is there a better >>solution? > >Yes. Use "class_default_for_X" methods. (e.g. "def >class_default_for_index_html"). This will make them capable of being >overridden with a Class Extender in the Rack or Specialist. Class Extenders! Wow! I mean, Wow! I mean, this is great! Let me catch my breath... I got to learn to look under my nose more often. I just assumed that everything in the DataPlugins Add menu (other than Link to Parent Plugin) was made redundant by the use of SkinScripts. Just got to figure out the best way to use them... with class_default_for_X there won't be any ZODB-accessible default code to develop on, so for UI methods, creating the Class Extender along with the Rack, and filling it with default DTML methods might be a better idea. > >Next, I need object connections - these are created using >>SkinScripts. And as far as I can tell, I can't manage SkinScript in >>the product - they have to be in the ZODB. Which is ok in O-O land as >>they're not strictly part of the PD classes, but this means that PD >>classes don't actually work at all until someone comes and fills in >>the SkinScripts - so the class actually misses a lot of the code it >>requires to function. Also, it means SkinScript code can't be reused > >>with the rest of the application's components (except by cutting and >>pasting code pieces from an existing application). > >Your factory code can set this up, although I admit it's ugly. But when I run the factory code the SkinScripts don't exist yet... I create my DataSkins and install my Specialists and Racks first, then develop the SkinScript required by them... so the Python product never contains all the application code... unless I copy the SkinScripts back into the product. The problem here is that I don't write a general-purpose app that will later be customized into a working project - I write a custom app for a specific project, which I will later want to reuse. So when I finish development of the first app, parts of it are in the ZODB. At this point, copying them back into the product makes sense for the purpose of instantiating new copies of the product, but not for that app itself, because maintenance/bug fixes will still be done on the ZODB copies. > >Finally, I need to wrap the whole thing up as an application. So I > >create a Folderish class which installs instances of all Specialists, > >and add application-wide utility methods. Or do I simply place all > >Specialists in a Folder? > >Placing them in a folder would be fine. Actually, it would suffice simply >to install a meta type which creates all the Specialists in the selected >folder. Note that Zope does not require that a meta type correspond to >some physical class, or that an add operation result in a single object >being added to a container; you can add as many objects as you want in the >same oper
Re: [Zope-dev] State of ZPatterns
Phillip J. Eby wrote: >At 10:16 AM 3/11/01 +1100, Itai Tavor wrote: >> >>I'm wondering where TransWarp leaves ZPatterns users. Until a couple >>of weeks ago ZPatterns was the best thing to happen in the Zope world >>since, well, Zope. Now it's described as a 'hack', > >Those things aren't mutually exclusive, you know. :) I realize that... I just got the impression that your own view of the value of ZPatterns suddenly took a nose dive. Guess I was wrong, and I'm happy to know that. > >demoted into >>'maintenance only' mode, and superceded by something that is >>described as being as much better than ZPatterns as ZPatterns was >>better than standard Zope development. > >It hasn't been superceded. TransWarp has several layers of functionality >planned; only one of those layers has been released to date. (By the way, >I also don't recall ever saying even that TransWarp was "better" than >ZPatterns, let alone that it was some giant leap forward. I did say that >it expanded further on the model which was the basis for ZPatterns, however.) Sorry for putting words in your mouth. My understanding was, though, that TransWarp will replace ZPatterns as the best tool for object model based development, which means that the idea of developing ZPatterns code with a view for long term future reuse suddenly isn't that attractive. > >As for "maintenance only", ZPatterns hasn't had any changes in months, >except for patches provided by its users. That's largely because it hasn't >needed any. There's not much you can *add* to ZPatterns, without a major >upheaval. I figure, let the major upheaval be directed at making something >completely different, rather than have major reworking to make something >only marginally better. I fully agree. I just didn't expect something with a 0.4.3b2 version number to remain unchanged. Also, I remember you mentioning that you're working on an SQL DataSkin. If that was really a possibility in the past, and it won't happen, then it's a major loss. Documentation/examples is another area that still needs to be improved (although the community can be considered to be responsible for that as much as yourself). > >So what do we do now? Wrap up current ZPatterns work, writing it off >>as a loss for future reuse? Or can we count on 'maintenance only' >>being sufficient to support continued reused of ZPatterns efforts >>long enough to justify the original development effort? > >Someone asked a similar question of me at the conference. I told them that >if I needed to develop a web-based application today, I would use ZPatterns >with Zope. It works, it's stable, it gets the job done. If you use it for production sites, that's good enough for me :-) > >Also, recall that the RIPP model concept was introduced to the Zope >community last January, and it was many months before ZPatterns' first >release, then many more before it was stable enough to be ready for >production use. Expect the same to be true of TransWarp. The tools >released so far are rock solid, but there isn't anywhere near enough there >to compete with ZPatterns yet. This is ok as long as you're choosing a tool per project. But I'm hate repeating work, and I expect the ZPatterns-based e-commerce app I'm building today to make the e-commerce app I build in 12 months a lot easier to build. So any changes in the basic tools I use bother me. Anyway, you did well calming my concerns. Thanks for that, and for releasing ZPatterns in the first place. -- -- Itai Tavor -- "Je sautille, donc je suis."-- [EMAIL PROTECTED]-- - Kermit the Frog -- -- -- -- "If you haven't got your health, you haven't got anything" -- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FTP interface being worked on?
Hi folks, Is anyone working on the FTP support in Zope? For our project, we'd like to improve the FTP interface to Zope. I noticed that ZServer/README.txt in Zope 2.3.1b1 states Properties and FTP: The next step The next phase of FTP support will allow you to edit properties of all Zope objects. Probably properties will be exposed via special files which will contain an XML representation of the object's properties. You could then download the file, edit the XML and upload it to change the object's properties. We do not currently have a target date for FTP property support. I have a proposal written up, if anyone is interested in providing feedback to me before I start work on it. Along these lines, I also have a proposal to add an export / import feature that would dump objects in the ZODB to separate files in a directory tree. (Currently the XML export seems to create one big XML file.) The goal is to allow objects to be managed as flat files so you can edit them more easily and use CVS to track revisions. Also, it sure is confusing to try to figure out where you accept patches. Is the Collector still the best place to send them? Thanks, Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: External Attribute Provider question
At 07:48 PM 3/11/01 +, Steve Alexander wrote: > >Is there a good reason that ExternalAttributeProvider sets up a >dictionary to put its attributes into, rather than a PersistentMapping? It's mainly to avoid a proliferation of persistent objects, based on the assumption that if you're using a PEAP, you probably don't have that much else in the PersistentMapping. >If an External Attribute Provider instead set up a new PersistentMapping >in its slot, only that PersistentMapping would change in the ZODB on >updates. > >Do you think this is a reasonable change for the External Attribute >Provider class? Or, should I write my own provider, derived from >External Attribute Provider, that uses a PersistentMapping instead of a >dict? I would suggest creating your own provider(s). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPatterns: External Attribute Provider question
Hi Phillip,
Is there a good reason that ExternalAttributeProvider sets up a
dictionary to put its attributes into, rather than a PersistentMapping?
This is the way it seems to store things in the Rack:
Rack's BTree
|
+ object_id
: PersistentMapping
|
+ ('ZPatterns.Rack', 'Self')
: Persistent object, eg ZClass instance
+ ('ZPatterns.AttributeProviders','ExternalAttributes')
: {} # dict filled with external attributes
The thing is that when the dict gets updated by the External Attribute
Provider, the whole second-level-in PersistentMapping object gets updated.
If an External Attribute Provider instead set up a new PersistentMapping
in its slot, only that PersistentMapping would change in the ZODB on
updates.
Do you think this is a reasonable change for the External Attribute
Provider class? Or, should I write my own provider, derived from
External Attribute Provider, that uses a PersistentMapping instead of a
dict?
Actually, I can see the use for a Persistent AttributeProvider where you
have a configurable slot, so you can group attributes that change at
different rates in groups of those that change together.
The second half of the slot-key's tuple would be configurable as a
property on the attribute provider.
--
Steve Alexander
Software Engineer
Cat-Box limited
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Ensuring 'freshness' of dynamic pages (slightlyofftopic)
On Sun, 11 Mar 2001, Morten W. Petersen wrote: > but no such luck. If I for example specify 'Check against server: Never' > in IE, the pages are cached, no matter what. > > Is it possible to ensure that pages are always fresh, even if it is > specified on the client side that the client should never try to > retrieve a 'fresher' page? In my experience, IE cache control is badly broken. Using the random id in the URL is, as far as I've been able to figure out, the only way to *guarantee* a fresh grab. There have been several discussions of this problem on the mailing list in the past, and you can certainly experiment with all of the suggestions that have been floated...but I don't know of a definitive solution other than the random id. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Ensuring 'freshness' of dynamic pages (slightly offtopic)
Hi guys, I've been trying to ensure that documents from a certain website are always fresh, that is, every request for a new page must be validated before the client sees it. I've tried using these HTTP Cache-control directives: no-cache no-store max-age (1) must-revalidate but no such luck. If I for example specify 'Check against server: Never' in IE, the pages are cached, no matter what. Is it possible to ensure that pages are always fresh, even if it is specified on the client side that the client should never try to retrieve a 'fresher' page? I've been contemplating a new solution, which is to append a string like ?ensure_freshness=02349025180.12 (some random, unique id) on each link, but that's not a thing which I wish to do now, at such a late stage in the project. Also, it strikes me that it isn't possible to specify multiple cache-control directives with the current HTTPRequest implementation, am I missing something here, or is this a bug / missing feature? Any ideas? Thanks, Morten ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FYI: TransWarp talk slides posted
HTML Version (frames & JavaScript required): http://telecommunity.com/TransWarp/IPC9Talk.htm PowerPoint Version: http://telecommunity.com/TransWarp/IPC9Talk.ppt ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
