[Zope] Recursive aquisition: good or bad?

Ty Sarna tsarna@endicor.com
7 Jun 1999 20:44:26 GMT


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.