There is a TemporaryFolder class in Zope. It's in lib/python/Products/TemporaryFolder.py and its named MountedTemporaryFolder. I recommend against subclassing MountedTemporaryFolder unless you want to spend the time to understand ZODB "mounting". A temporary folder is an object that is a mount point. It mounts a TemporaryStorage-backed database and masquerades as its root object. When you traverse one of these things, the __of__ method of the mount point object is called, and that returns the a Folder object that actually lives in another ZODB. To understand it fully, you'd need to read the source of TemporaryFolder.py and MountPoint.py. It's not always the most obvious of code, but it's not too terrible. But I honestly don't think using a TemporaryFolder for this is the right thing here. Your object should return different images when different methods are called on it, and each method should have its own URL. Get that working first, then integrate caching into it as an add-on service. You can try RAM Cache Manager or simple module-level globals keyed on the Zope physical path of your objects. This is not dumping the complexity up a level, it's just using existing services to speed things up (it won't "fail completely", your system will work without caching, just not as fast). On Sun, 2002-08-11 at 18:17, Terry Hancock wrote:
Chris McDonough wrote:
Even better, maybe just use RAM Cache Manager and give each resized image its own URL?
On Sun, 2002-08-11 at 09:31, Chris Withers wrote:
Terry Hancock wrote:
Hi all,
I'm finally revisiting the nasty part of my code that periodically hoses itself and fails to deliver resized images. ;-D
As a small idea, rather than inheritting from Image and TemporaryFolder, why not subclass Image (but only if you need to change its behaviour ;-) and then store you images in the Temporary Folder in the root of your ZODB?
Naturally I need to change Image's behavior, and indeed every image does get its own URL (this improves browser caching as well as any upstream caching). But for the system to essentially fail completely without a RAM cache manager is poor design, IMHO, and puts unnecessary constraints on the installation, when the product should really take care of this on its own.
Likewise, using a centralized temporary folder puts complexity into the ZMI, when it shouldn't be there. I would then have to create a scheme of URLs for the temp storage distinct from the original location of the images. That's going to be very ugly. It's better to have the caching going on essentially at the source object.
I considered and rejected both of those designs for what I consider to be good reasons. VarImage is a utility class and gets used for several different things in several places. To dump the complexity up a layer to the calling code just doesn't make sense.
I *had* considered making the temp folder *contained* by the Image and not a superclass of it. But I'd still like to understand how and why a Temp folder comes into being. The source is not immediately transparent on this point. Why did it need to be different from other Zope objects? Why is there no such thing as a "Temporary Folder" class in Zope? I thought we liked object oriented programming. ;-D Now all of a sudden we abandon it. There must be a reason for that.
It seems to me that it's impossible to subclass Temporary Folder, because there's no such class. I'd like to think that's wrong.
Thanks, Terry
-- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------