[Zope] Recursive aquisition: good or bad?

[Michel Pelletier]

> -----Original Message-----
> From: tsarna@endicor.com [mailto:tsarna@endicor.com]
> Sent: Monday, June 07, 1999 4:44 PM
> To: zope@zope.org
> Subject: Re: [Zope] Recursive aquisition: good or bad?
> 
> 
> 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).
> 

This is very interesting and is similar to some of the workflow
constructs we've come up with, where we have different areas (what you
call 'modes') defined for the different actors in the workflow.  I'm not
sure if we've taken advantage of your 'multiple' methodology though.
Jeffrey?  Is this similar?

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

All right that settles it.  We're going to kidnap you and chain you to a
desk.

-Michel aka "Vinnie the Saint"

> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (For developer-specific issues, use the companion list,
> zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
>