[Zope-dev] Transparent folders?

Martijn Faassen faassen@vet.uu.nl
Thu, 27 Apr 2000 15:10:25 +0200


Hi there,

Recently I've had an idea.

Problem description:

I'm sure lots of people will recognize this.

The root folder fills up with lots and lots and lots of methods; both
factored HTML layout components and methods that should apply to all
subfolders.

Ideally you'd want to put this stuff in subfolders. But you run into the
following problem: acquisition works no more. That is, acquisition works,
but to override any specific layout component that's in a subfolder,
you need to override the entire subfolder and copy over *all* layout
elements. That's not what we want. I haven't seen an easy solution to
this problem yet, unless I'm missing something.

Analysis:

So, why do you want to use folders at all? To compartementalize the
system so we can easily find stuff. To avoid long lists of methods in
the root folder. But proper folders hurt acquisition, so..

Solution:

We need a new type of folder, the 'transparent' or 'virtual' folder. 
If we have a folder 'folder', and a subfolder 'sub', and sub is
a transparent folder, anything we place in 'sub' is actually in 'folder'
as well. It'll be acquired. It can be overridden (either in a subfolder
of the same name, or in the folder that's doing that acquiring directly).

This way, we get to compartementalize things while keeping the benefits
of acquisition.

Actually, this idea could have deep consequences, as it's getting very
close to (multiple) inheritance. That is, if you put a transparent folder
in your folder, it's like saying the current folder inherits from that
transparent folder.

Perhaps transparent folders could then also be generalized for
a new type of ZClass inheritance that may or may not be easier to manage than
the current system. Imagine being able to drop a transparent folder in
your ZClass to make it inherit the methods in that transparent folder. ZClass
inheritance needs an extra bit, though; the ability to make a 'reference'
transparent folder that does not have actual methods inside itself, but
just refers to some other ZClass (or Python base class, or whatever).

Let's just stick to my original transparent folder idea for now, keeping
all this inheritance zen in mind for later. My questions are:

  * is this a good idea at all? Any disastrous complications or consequences?

  * is this technically feasible?

Regards,

Martijn