In article <613145F79272D211914B0020AFF640191BF133@gandalf.digicool.com>, Michel Pelletier <michel@digicool.com> wrote:
It's 'featurish'. This kind of thing falls under the feature/bug anti-duality law. It's not a bug, because it's doing exactly the right thing, it's not a feature, because it's generally not very useful. I can imagine a situation somewhere in which it is useful (don't call my bluff) but I can also easily immagine situations in which it's not very useful at all (below).
Definately a feature. Both of the production Zope/Principia installations I'm responsible for now (and one of them is actually several sub-sites that could be separate) use this feature quite a bit. It's effectively a way to do "multiple acquisition" (in the sense of multiple inheritance.) One use is something like this: app/ mode1/ mode2/ mode3/ objects (that implement app) You can have the user access app/... for "regular" access, or app/modeN/... to get a different view on things, by having the mode folders have objects that override the ones in app with different behavior. The real advantage comes when different aspects of the modes are not mutually exclusive. then you can have app/mode1/mode2/... to get both, if things are designed properly. You can also have app/mode2/mode1/... do something different, by having mode1 override mode2 (whichever is last takes precedence... it's like changing the order of base classes in a class definition). In the sites I'm managing, the "modes" are some cases different modes (like "show me this as text", "show me this as html", "provide the ability to edit the data", which can possibly be combined, like html view with editing). In other cases the modes are actually different access levels. app may reference a DTML method "menu" in several places. app can contain a basic definition of menu with the basic choices and Anonymous view permission. You might have a "mode" folder called "author" which contains a method of the same name but with higher security restructions and that provide more choices. by accessing app/author/... instead of app/..., the user is forced to authenticate and will be given more menu choices.