Martijn Faassen wrote:
Hi there,
Recently I've had an idea.
Problem description:
I'm sure lots of people will recognize this.
The root folder fills up with lots and lots and lots of methods; both factored HTML layout components and methods that should apply to all subfolders.
Right.
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.
Ya lost me right there, where is there a copy involved? Why can't you put your Foo layout components in a FooLayout folder in the root folder and say: <dtml-with FooLayout></dtml-with> When you want to use them? The only downside of this from your approach is that it's not 'transparent'. But otherwise what you are proposing does make sense, I'm getting the impression of 'overlaying' various folder namespaces while keeping their organziational structure. Ok, some questions. What happens when a transparent folder 'A' contains a tranparent folder 'B'? So 'B' contains the object 'Foo' which you try to access from some completly different location. It is not found in the root folder, how is 'A' searched? Are all transparent folders in a container searched in a linear fashion? Does 'B' get descended into when A doesn't contain Foo? This begins to sound like an expensive recursive lookup unless a transparent folder plays with the namespace of its container, but then I think you run into a whole other slew of problems, like why Zope complains to newbie eyes that the id 'Foo' exists when it clearly doesn't in the root folder (oops, gotta look in A/B!, but if there's lots of these transparent folders, you're lost). What if both A and B contain a 'Foo'? Is B's Foo ever visible to anyone other than explicitly? -Michel