Hi, I've been following this thread as it may have very bad consequences for me. I'm currently developing a product which relies Transparent Folders, and I've been told that I need to upgrade to avoid some bugs, which I've been encountering in development (Python 2.1.1 + Zope 2.4.3, which is supposed to have known problems). I was planning to upgrade straight to Python 2.1.3 + Zope 2.5.1, especially since I have an application for "TempFolders", at least as soon as get to a reasonable breaking point. (I'm fairly paranoid about upgrading dependencies in the middle of development, as it usually breaks stuff, and I really don't need (my bugs) x (other bugs) to solve!) Eliminating TFs would be a major pain, and for anyone in the "don't use them, they're bad" camp, I challenge you to find a better solution (yeah, okay, I'll say it's a "friendly" challenge, but still...). Let me illustrate what I mean: APPLICATION #1: Clearing mgmt folders ------------------------------------- This is the one everyone talks about, but I will emphasize here that this is not merely for my benefit, but also directly visible to my users (who will often be customers). The site, as designed, will have top-level common areas, as well as subfolders for particular users. Some areas (home folders) will be flat, but others (project folders) will be self-similar recursions of the top folder). The site is image-intensive, so we have images stored in subfolders, generally according to their function. For illustration, I'll only use the "Image" folder, but there are others. Potentially, we have something like this: TOP | +------------------+-------------------+ | | | | | Image Project Home | | +------+ +-------+ | | * | | Image Image Sub- Project | +------+ * | Image In this illustration "*" represents a collection of various other files, and all the "Image" folders are transparent. Because of TFs, a user can put their own images in Image which will overload or complement images in the image directories above them. So, ordinary users can use their own images and anything in the common image directory, while projects can use the public images, provide their own for subprojects, or use specialized ones in each subdirectory. This is important because the different locations are subject to different permissions: only the user (and an administrator) can access a users folders, and only a project moderator can access project files -- which is self-similar in the sense that the moderator can assign a sub-moderator to a sub-project. This has various consequences, including legal ones: Under one of the not-so-evil clauses of the DMCA, I can't be (or can't easily be) sued for copyright violations that a user makes. Less controversially, that user may have legitimate copyright or trademark protection on their images and not want to share them with the whole community (e.g. personal avatars or commercial logos). In any case, I don't want to force them to share all their content by putting it in the top level shared folder. Without TFs, however, if the user added an Image directory, it would shadow the global one, and that's not what we want. There is a workaround, in that I can *tell my users* to use a URL like this: Image/Home/<username>/Image/ instead of Image/ I emphasize that this is not a requirement on me, the developer, but on my user, "For whom all things must be made simple". Also, in contrast to the filter argument made earlier in this thread, this CANNOT simply be the result of filtering for "Image" filetypes. There are many types of images, some of which shouldn't be mixed into this hierarchy (graphical buttons, for example). Besides, it gets worse, with ... APPLICATION #2: Organizing content classifications -------------------------------------------------- Now, I mentioned that we have shared content (both at the top level and in projects). That content is not all under the same license terms, though -- some may be Public Domain, BSD-type, GPL, DSL, etc. So, we subdivide the Image folder(s). Furthermore, the art is usually in collections, not just random isolated images. So, for example I have a collection of art based on Tenniel's Alice in Wonderland illustrations (thank you, Project Gutenberg!) and another set collected by the University of Oldenberg in Germany, based on scans of "old, heavily illustrated children's stories". So I'll put these two directories beneath PubDom -- the other areas will likely acquire such divisions as well: Image | +------+------+------+------+ | | | | | PubDom GPL BSD DSL CF | +--------------+-------------+ | | * AliceTenniel Oldenberg Now, *these* are *all* transparent folders, because I want to be able to get the images by simply searching "Image", not by having to remember each subdirectory. If I want to do this with plain Zope acquisition, I'll need to tell my users to thread through all possible directories, like this: Image/PubDom/AliceTenniel/Oldenberg/GPL/BSD/DSL/CF/Home/<username>/Image (Note that it's easy to screw this up, Image/PubDom/GPL/BSD/DSL/CF/AliceTenniel/Oldenberg/Home/<username>/Image won't work, for example). Which I again emphasize, is a requirement on my user, not just me. The directory tree above allows me to put collected attribution information into a README or some such, without necessarily having to verify that each image has attribution information in a property, for example. Furthermore, this hierarchical arrangement is much more effective for users to browse the image collection (it's trivial to write a browsing interface in Zope to examine Image directories recursively, I'd have a much harder time using filters of some kind). Now, you may think that this is all "just cosmetic" or that I shouldn't worry about such trivialities, and just work around this problem, but really, *I* think I need transparent folders. --- So, if my use-case convinces you, can I please ask what the deal is with Transparent Folders in Zope 2.5? Can I upgrade, or what? I actually don't care too much about Session tracking, though I would really like to use TempFolders, as they solve a server-side caching problem I'd like to do in Zope (instead of relying on a front-end cache, for example). That's another problem entirely, but a constraint nevertheless. I've also had problems subclassing "Folder", even in very trivial cases (e.g. I have one object that if I call "absolute_url" on it, gives me the parent folder's URL instead of its own -- is there some step I'm missing? I haven't even overloaded the __init__ -- I've just subclassed folder, changed the meta_type and added a couple of methods which I'm pretty certain are not overloading anything -- manage_addFolder() seems to be very simple, especially if you eliminate the "Create User Folder" and "Public Interface" options, so I don't see how I can be missing anything.) So I'm a little leery of recoding a specialized TF for my purposes, as it certainly seems there are lurking problems to bump into. Should I try Python 2.1.3 + Zope 2.4.4? Or can I go ahead with Python 2.1.3 + Zope 2.5.1? I've already run into bugs with my current configuration (at least I *hope* they're the known Python/Zope bugs!). Anyway, any ideas, advice, or comments would be appreciated. Cheers, Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------