On Thu, 22 Jun 2000, Patrick Lewis wrote:

Try changing /index_html as follows:

<dtml-var standard_html_header> <table> <tr><td><dtml-var "PARENTS[0].text_object_1" fmt=structured-text> </td></tr> <tr><td><dtml-var "PARENTS[0].text_object_2" fmt=structured-text> </td></tr> </table> <dtml-var standard_html_footer>

Basically force Zope to look in the current folder first.

Additionally: Is your root index_html a DTML Method or a DTML Document? If it's a DTML Method, it should work as you desire; DTML Methods are the odd bird, and acquire differently than everyone else. DTML Methods acquire other objects from the context in which they are called. This is how standard_html_header and standard_html_footer work. DTML Documents, however, acquire like every other Zope object, and will behave as you have described: acquire text_object_1 and text_object_2 from the actual location of the DTML Document. --Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:jeff.hoffman@goingv.com Going Virtual, L.L.C. http://www.goingv.com/

Luciano Ramalho wrote:

zoper@creative.isquare-asia.com wrote:

...

The effect I would like to achieve is: when user access http://myserver/, content of /text_object_1 and /text_object_2 will be shown while user access http://myserver/subfolder/, content of /subfolder/text_object_1 and /subfolder/text_object_2

The point is that there's no index_html in /subfolder so /index_html will be acquested and by default it displays content of /text_object_1 and /text_object_2

The question is: we got text_object_1 and text_object_2 in /subfolder how could I let the acquested index_html in subfolder to use the objects inside the subfolder?

What you want is what Zope already does!

That is how acquisition works: if /subfolder has no index_html, it will acquire that object from the root. But the DTML inside index_html will be rendered in the context (namespace) of the subfolder, so the desired effect will be achieved.

Unfortunately it is not quite as simple as that. Infact, to say that that is how acquisition works is misleading. It is not how acquisition works, but if you are using DTML Methods then you can create the effect of that being the way it works. Let me explain. When you acquire an object, the acquisition method used is to first look at the containment of the object before the context of the object. So if you have the scenario described above, when you call /subfolder/ it fist looks for index_html inside subfolder, but it isn't there, so it looks in subfolders containing object, /, where it does find index_html. Now it executes index_html and finds a call to text_object_1. So it first looks inside index_html for text_object_1, but it can't find it, so it looks in the _containing_ object of index_html, /, and finds text_object_1. However, if index_html is a DTML Method then things are different, because a DTML Method does not have it's own namespace and isn't an object in it's own right - rather it is a method of the calling object. The problem with this *containment before context* is that in most cases it goes against what is trying to be achieved. In the example above, there may be very good reasons why index_html needs to be a document rather than a method - maybe it needs it's own properties, etc. The point is that most often, the important thing when calling an object is the *context* in which it is called, not the location in the object store where it happens to be located. As I have mentioned several times now on the list, I can't see any good reason why acquisition should use the containment before context method (refered to as Simplified Acquisition) and in my opinion it should be changed to use context before containment (refered to as Natural Acquisition). See http://www.zope.org/Wikis/zope-dev/AcquisitionUsage for some explanation of the different types of acquisiton, and http://www.zope.org/Wikis/zope-dev/AcquisitionFeedback for a summary of the problem as I see it - if you have opinions then do add them. Also, Patrick Lewis wrote:

Try changing /index_html as follows:

<dtml-var standard_html_header> <table> <tr><td><dtml-var "PARENTS[0].text_object_1" fmt=structured-text> </td></tr> <tr><td><dtml-var "PARENTS[0].text_object_2" fmt=structured-text> </td></tr> </table> <dtml-var standard_html_footer>

Basically force Zope to look in the current folder first.

That is all well and good for solving this particular problem, but it crosses a threshold in terms of accessability to the person writing the code. For a 'non-programmer', writing <dtml-var object> is not too difficult or scary, but <dtml-var "PARENTS[0].object"> is a world apart and quite a scary place to be. It's complicated, it doesn't make a lot of sense and it makes doing what should be quite simple things inaccessible. I work with a variety of people here, some of whom have no problem at all with any of the above, but others for whom there is a definite barrier between the first and second snippets of code. It's like the old "function(_, _.None) thing, which just shouldn't be necessary, but that's a different story. Anyway, in this particular case, if acquisition worked in a more useful way (see above) then this problem would be avoided. Cheers, Stephen -- Stephen Harrison stephen@nipltd.com New Information Paradigms www.nipltd.com

Luciano Ramalho wrote:

Thank you very much for the correction.

However, after checking your Wiki references, I must say I still don´t understand the difference between context and containment (these are words that I naively used as synonyms in my message).

In <http://www.zope.org/Wikis/zope-dev/AcquisitionUsage> we find:

""" - Containment: Search the object, then its container, then the container's container, and so on. Ignore objects not in this chain.

- Context: Search the objects in precisely the reverse of the order in which they were mentioned, so "A.B.C.D" is always searched in the order "D", "C", "B", "A".

"""

But for me, A.B.C.D means that A contains B; B contains C; and C contains D, so I don´t see the difference from the first definition.

Maybe you are using the word "container" in a more restricted sense?

This is how I see it: containment doesn't change, while context can, but is often the same as containment. So you create a method called "foo" and put it in /bar. "bar" is always that method's container. Then you create another folder called "boo" at the root. Then you access http://myserver/bar/foo . In this case, the context is the same as containment. But if you access http://myserver/bar/boo/foo , you're accessing foo in context of boo. The containment doesn't change--foo is still in bar. But the context is boo. Acquisition always searches the containers first, then the context. This may not appear to be inuitive, and it may seem sensible to search only the context, but actually that would break security--imagine being able to access someone else's folders in context of a user folder you own. In the case of http://myserver/bar/boo/foo, then, a name lookup searches boo, then the container of boo (the root folder). If the name hasn't been found yet, the lookup moves up in context to bar, then the container of bar (the root folder again). Does that clear it up? Shane