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