[Zope] Re: [Zope-dev] Transparent folders?

[Jason Spisak]

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.