Martijn:

...

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.

I think we are saying very similar things. I re-read your email, and I think understand some of the differences. You are just talking about trans-folder aquisition. The idea that a "Folder" object stop the acquisition of certain objects is what you want to address, right?

...

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 :).

Agreed. It physical was a mis-nomer.

...

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?

Just because you wanted some sort of code reuse of the smaller, more specific items down the tree. You see, I never really have used zope to split up content into "topics" or "catagories" with Folders. Probably for the very reason you are suggesting. It's too hard to work around.

You could simply have a vast amount of unorganized objects with a catalog on top of it, and this would be perfect, right?

But the organizations that objects have to one another can be visually represented by trees if you wanted. But that wouldn't be the only way. And something wouldn't belong to only one tree. I think we are saying the same thing.

Or do you say we only organize things in a tree for acquisition, and not because the site might look like a tree?

See above.

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.

Not now, no. But there is no aquisition mechanism other than placement in the tree right now.

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.

It seems orthogonal with what you're proposing, if I understand you right.

I think so. All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.