[Zope-dev] Transparent folders?

[Jason Spisak]

Martijn:

> Recently I've had an idea.
>

Excellent. 

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

Yes it's a problem I have encountered.  I have been forced to let the site
get unorganized in order to take advantage of acquisition. However, for
layout, I have started uwins a UIClass ZClass that my objects inherit from
and I can reuse my code, so I don't have that problem as much anymore.

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

<snip>

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

I think developing a new class to organize things with a "management
interface" focus is taking a step backwards.  The physical location of an
item is important because of aquisition.  But the *physical* location of an
item is not important to organization.  I think that the two should be kept
separate.  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.  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.

2 cents gingles in the jar.

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.