[Zope-dev] Transparent folders?

[Martijn Faassen]

Jason Spisak wrote:
> Martijn:
> > Recently I've had an idea.
> Excellent. 

Happens all the time, really. :)

[snip]
> I think developing a new class to organize things with a "management
> interface" focus is taking a step backwards.

Why is this 'management interface' focus, though? Obviously we construct
our site through the management interface. But the transparent folder
would not be something of the management interface; it's a new way to
organize objects.

> The physical location of an item is important because of aquisition.
> But the *physical* location of an item is not important to organization.

I happen to disagree. I think the location of an item in the folder
tree is important to site organization. (I don't think the word 'physical'
makes much sense in a situation where we have abstractions heaped upon
abstractions already; a file is an abstraction, the object database is
an abstraction, the tree is an abstraction, and then the catalog is
an abstraction too :).

> I think that the two should be kept separate.

But they're not. If they are to be kept seperate, why organize your
objects into a folder tree at all? You could simply have a vast amount
of unorganized objects with a catalog on top of it, and this would be
perfect, right? Or do you say we only organize things in a tree for acquisition,
and not because the site might look like a tree?
 
> The Catalog allows you to manage items (very clunky) regardless
> of their location.  You could very easily group those items for
> organization without effecting their physical place in the hirearchy.

I'm not sure I follow you here. How would this help with the acquisition
and organization problem I mentioned? As far as I'm aware, you can't
use the Catalog to 'pull' an object into a folder and let it be acquired,
right? Even if it were possible, this would be clunkier than the
transparent folder approach, though more powerful. 

> This goes along with establishing object relationships that are not 2
> dimensional(hirearchy), but multi-dimensional(those 'relationships' or
> 'links' that pop up on the list every month or so). I truely think that
> physical location shouldn't be the only effect on aquisition.

Right, and wasn't I proposing something to deal with that exactly? I agree
that somekind of 'reference' or 'soft link' system would be useful. But
having such a system still would not solve the acquisition problem that
I pointed out in my previous mail. You still end up with folders full of
methods that are to be acquired. The transparent folder idea attempt to
solve that.

If you then add references, that would be useful for even more
organization, later, in *combination* with transparent folders. You can then
pull in objects into a folder from somewhere else completely; you can 
share the same sets of layout components across multiple independent
trees, etc. In combination with ZClasses, it'd allow you to easily change
the base classes of a ZClass. A smart kind of reference may even bring
ZClasses outside the Product screen entirely, into the main tree. Define
a ZClass for just one particular subtree, etc.

Anyway, that's all speculation. I haven't understood yet what you think is
wrong with the 'transparent folder' proposal. It seems orthogonal with
what you're proposing, if I understand you right.

Regards,

Martijn