Re: [Zope] Zope 2.5 and TransparentFolder incompatibility
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
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 ------------------------------------------------------
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
participants (2)
-
Joachim Werner -
Terry Hancock