[Zope] Temp Folder Magic

[Chris McDonough]

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
> ------------------------------------------------------