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