[Zope] Zope 2.5 and TransparentFolder incompatibility

[Joachim Werner]

Hi!

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

That depends. The only thing that actually could break is accessing stuff
via URLs of the type "/Images/whatever.gif". That means that at least on
root level you'd need your Images folder ...

But it IS in fact an ugly solution ...

> > 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 am no real expert at acquisition mechanics, but subclassing from Script
sounds dangerous to me. I'd just subclass from Folder and override some of
the methods. AFAIK, the one you'd need to override for getting different
acquisition behaviour would probably be __getattr__().

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

Having 1000 or more objects on one level in the tree is surely not
efficient. But if you use TF, this won't become better but worse. It would
LOOK better in the ZMI, but actually you'd end up with thousands of
recursive __getattr__ calls. Only taking REAL folders to structure your
stuff would help. BTW: With more than a couple of hundred objects, I'd use
BTreeFolder for efficiency.

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

I THINK you'd have to override __getattr__ as I describe above.

Joachim