[Zope] Zope 2.5 and TransparentFolder incompatibility

[Terry Hancock]

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