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