[Zope] Zope 2.5 and TransparentFolder incompatibility

[Joachim Werner]

Hi!

Some notes on Transparent Folders (TF):

a) We've been using TF heavily and we really regret it. The performance hit
is enormous, especially if you have nested TF. We got response times up to
10-15 secs on a fast Athlon server with loads of RAM. That's extremely bad.

b) I don't know why TF should not work fine with Zope 2.5.1. We were using
OrderedFolder with transparency support enabled, and that worked. Maybe
there are issues with plain TF, I don't know.

So, yes, eliminating TF in your product will be a major pain, but I'd rather
do it anyway (even if you don't HAVE TO eliminate them for compatibility
reasons).

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.

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.

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

I am not Zope3-literate yet, but I was told that Zope3 will offer much
better solutions for problems like that.

We'd need additional namespaces. E.g., you are using transparent Images
folders to make sure that one can overload certain images locally without
having to overload all images. What you'd really need is not TF, but an
image namespace (let it be represented as a folder or not) that looks up in
other image locations if an image is not found locally. That's similiar to
what skins do in the Content Management Framework.

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

Joachim