Michel Pelletier wrote:
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?
You can't exploit acquisition so easily then. You can use a FooLayout folder. Now you suddenly (for some bizarre reason) want to support a Dutch version of the site in some seperate subtree, with different texts, images, and so on. But not *everything* is replaced. You want to change some of the stuff in FooLayout, for instance 'header_html', but not all of it. I can't simply reate my own FooLayout in /dutch, and put my own header_html there. I'd need to copy over *everything* from FooLayout to make that work. Of course there are some ways around that, but they all seem to be a hassle compared to what's possible with acquisition.
The only downside of this from your approach is that it's not 'transparent'.
Does this mean you understood what I meant already? That was the downside I was trying to solve. :)
But otherwise what you are proposing does make sense, I'm getting the impression of 'overlaying' various folder namespaces while keeping their organziational structure.
Right. That's another way to look at it. It's quite analogous to inheritance, except that the base classes are defined 'inline'.
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
True. I don't know the fine details of the acquisition machinery, but presumably there's somekind of 'expensive recursive lookup' involved at some point too. Would this increase the expense that much compared to the current situation? (Ignoring the fact that much of acquisition happens in C)
unless a transparent folder plays with the namespace of its container, but then I think you run into a whole other slew of problems,
Probably. :)
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).
Right. You could work around that with error reporting, perhaps, but that'd be a pain. Better behavior would be that 'Foo' in the root folder simply overrides any other Foo's in A or B. I think you can make the playing with the container's namespace smart enough to do that. Not that it still wouldn't be tricky. We haven't even thought about any security implications yet, for instance.
What if both A and B contain a 'Foo'? Is B's Foo ever visible to anyone other than explicitly?
Yes; A's Foo would be found. Another question that I *can't* answer is what if I have transfolders C and D, and they both contain Foo. Which one gets found? This is analogous to what can happen in multiple inheritance in Python, but it's less clear what the order of depth first search in Zope is. Thanks for your comments. Very useful. Regards, Martijn