[Zope] (Fwd) Re: [Zope] Changing Contexts (Was: [Zope] Acquisition? D

[Rik Hoekstra]

> Paulo Eduardo Neves wrote:
> > 
> > "Jay R. Ashworth" wrote:
> > >
> > > Got it.  Then, I agree with the other folks.  How can you override the
> > > context of the place where you acquired it _from_ with the context of
> > > the place where you acquired it _to_?  That would seem to be a very
> > > important ability...
> > 
> > It would be really nice. Beyond a /noframes version we'd do things like:
> > 
> > 1) Have a /print folder so if we call /print/mypage instead of /mypage
> > the result would be a printable version of the page.
> > 
> > 2) A /text folder where all image objects would be replaced by dtml
> > methods giving us a text version of a site.
> > 
> > 3) Any kind of /otherDesign folder with a customized version of your
> > site. Nice for syndicalization.
> > 
> > 4) A /german folder that have a LANG="de" property to make a german
> > version of a site. It would be easy to have a multilingual site.
> > 
> > Is it possible to code a special kind of folder that changes the
> > aquisition order?
> 
> One thing I'd like to point out here, is that you are getting into
> something very, very deep.  This discussion has gone pretty far, but I
> still dont get it.  What I want to see is a very, very trivial example
> of what you want to do, and why you can't do it now.  There may be
> another solution.

A simplified example (with a verbose introduction :-))

i have a web courses product in the making, which should enable 
teachers to easily use the web; managers of a courses site should be 
able to provide a consistent look and feel (that is a user interface, 
standard components etc)

A course is a folder (or folderish product or ZClass instance) with 
just (possibly complex) content. The user interface is responsible 
for presenting this to the users (students, teachers etc).

For a demo in my faculty I wanted to show that 
1. making a course and adding components was easy
2. changing the user interface _and_ standard components was also 
easy

Thus facilitating two types of users (managers and teachers)

The easiest way to solve this (i thought until peer acquisition got 
in the way) was to move the user interface part and friends to a 
department folder. In this way content would be provided through a 
URL.

/courses/demo/dept1
/courses/demo/dept2

where courses, dept1 and dept2 were all on the same level, and dept1 
and dept2 used material from the folder above it (such as an indexing 
method of the objects in the course - in one case a tree and in 
another a simple list of components). This did not work because the 
index_html was inherited from the topfolder.
What worked was changing the order of the url (and thus of 
acquisition) from 

/courses/dept1/demo/
/courses/dept2/demo/

But this broke the tree indexing method, so it was not the solution.

I decided I was to stupid for this and made separate folders courses 
in the respective dept1 and dept2 folders. This worked, but wasn't 
quite satisfying. 

hope this clarifies things

Rik