Re: [Zope] Reversing acquisition?

[Shane Hathaway]

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

___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Reversing acquisition?

[Luciano Ramalho]

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

Best regards,

Luciano Ramalho


Stephen Harrison wrote:
> 
> Luciano Ramalho wrote:
> >
> > [EMAIL PROTECTED] 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:
> >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 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  is not too
> difficult or scary, but  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 wor

Re: [Zope] Reversing acquisition?

[Stephen Harrison]

Luciano Ramalho wrote:
> 
> [EMAIL PROTECTED] 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:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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  is not too
difficult or scary, but  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[EMAIL PROTECTED]
New Information Paradigms   www.nipltd.com

___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Reversing acquisition?

[Luciano Ramalho]

[EMAIL PROTECTED] 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.

Regards,

Luciano Ramalho

___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Reversing acquisition?

[Jeff K. Hoffman]

On Thu, 22 Jun 2000, Patrick Lewis wrote:

> Try changing /index_html as follows:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Reversing acquisition?

[Patrick Lewis]

Try changing /index_html as follows:










Basically force Zope to look in the current folder first.

--
Patrick Lewis <[EMAIL PROTECTED]> 

On Thu, Jun 22, 2000 at 11:03:37PM +0800, [EMAIL PROTECTED] wrote:
> Hi All,
> 
> Here's the situation
> 
> I have a tree such that
> 
> /index_html
> /text_object_1
> /text_object_2
> /subfolder/text_object_1
> /subfolder/text_object_2
> 
> where content is:
> 
> /index_html
> 
>   
>   
>   
>   
>   
>   
> 
> /text_object_1
> 
>   Just some text of text_object_1
> 
> /text_object_2
> 
>   Just some text of text_object_1
> 
> /subfolder/text_object_1
> 
>   Just some text which is different from /text_object_1
> 
> /subfolder/text_object_2
> 
>   Just some text which is different from /text_object_2
> 
> 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?
> 
> If my desired effect could be achieved, that would be very useful
> as the whole site could use a master template at root, changing objects
> inside folder could show different content. While changing the root
> index_html will change the layout of the whole site
> 
> Otherwise we have to put the same "index_html" inside every folder
> so that default view of folders will show their containing object content.
> 
> If this is not easy, is there any other way to achieve the same effect?
> I don't want to use something like "http://myserver/?c=some_parameters"
> which is my current implementation (where site structured is not preserved
> or shown by URL)
> 
> Thanks,
> 
> Roger
> 
> ___
> Zope maillist  -  [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )

___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )