[Zope] Zope 2.5 and TransparentFolder incompatibility

[Terry Hancock]

Hi Joachim,

Joachim Werner wrote:
> Some solutions for the problems you mention:
> 
> a) One idea is putting everything into one large root folder (and do the
> same for the subfolders). I.e., all the images would not be in an image
> folder but in the main folder. Then use FolderFilter to create views that
> only display images, content, etc. With some additional magic you could make
> sure that your end users don't see the stuff that could irritate them.

Eew. I think that would break more than it fixes.

> b) Write a method, e.g. "getImage()", that looks in the local Images folder
> first and then dives into the hierarchy. This is way more efficient than TF
> and has a similar effect.
> 
> I have to admit that dtml syntax becomes rather ugly with that ("<dtml-var
> "getImage('image.gif')">" instead of just <dtml-var image.gif>), but it
> works.

Hmm.  This may be more promising.

What would happen if I subclassed an object from both "Folder" and
"Script" and used "traverse_subpath" to catch accesses?  Could I
write my own acquisition behavior?   In other words, supposing the
"Image" folders were of this type, I would ask for, say:

/Image/alice1_png

and it would first look at Image.objectIds() (is this the best way
to look for a local object?) and then, assuming it didn't find it
there, it would try to find it using a customized acquisition process
(i.e. it would call your hypothetical "getImage()" method).

> I perfectly understand your problems, and TF seem to solve them elegantly.
> Elegantly yes. But not efficiently. That's the problem.

Point taken. But I do need to find an appropriate solution, and
pretty quickly.

Also, as an additional criticism on the "dump everything in the top
folder" solutions -- wouldn't I (still) run into performance problems
as the number of files becomes large?  I haven't really pushed this
limit myself, but I understand that the OFS, like many other
filesystems, will experience bad look-up delays when the number of
files is in the 1000s or so (which can happen pretty fast in my
application -- I already have a few 100 files to manage, and I
haven't even released this thing).

> I guess it would be rather simple to build a folderish object that uses a
> different way of acquisition (e.g. looks for other folders of its kind in
> the hierarchy).

Like I describe above, or should I be taking another
approach?

Thanks for the ideas,
Terry

-- 
------------------------------------------------------
Terry Hancock
hancock@anansispaceworks.com       
Anansi Spaceworks                 
http://www.anansispaceworks.com 
P.O. Box 60583                     
Pasadena, CA 91116-6583
------------------------------------------------------