How can I control the context within which the various built in methods execute? For example, I am using a tree tag in a document method to display subfolders in my global navigation. However, when this method is acquired by a subfolder, its context changes and it only lists the subfolders of the current folder. I want to force this method to execute within its original context in order to display the entire site structure regardless of the page being viewed. If this is not currently possible, I would like to suggest that a 'context' attribute be added to <!-- #var -->, with the default being 'context=here' (the current behaviour) and an additional value of 'context=self' or perhaps 'context=origin' being made available. Another possible value for a 'context' attribute might be 'context=parent' to move the context up one level in the hierarchy. What do you all think? Michael. P.S. I do not yet have the programming ability to accomplish this... so I cannot submit a patch.
On Tue, 2 Feb 1999, Michael Bernstein wrote:
If this is not currently possible, I would like to suggest that a 'context' attribute be added to <!-- #var -->, with the default being 'context=here' (the current behaviour) and an additional value of 'context=self' or perhaps 'context=origin' being made available.
Another possible value for a 'context' attribute might be 'context=parent' to move the context up one level in the hierarchy.
Lets suppose we have a document in the top level object named global_map with an entry like: <A HREF="<!--# var title-->"><!--# var title--></A> <A HREF="<!--# var BASE1--><!--# var title-->"><!--# var title--></A> How should the relative URL's or BASE variables be handled if this document is called from a subobject down the object hierarchy like <!--# var global_map context=origin--> ? Anyway if you do need to access the parent of a given object you can use: <!--# var "aq_parent.<whatever method you want to call>"--> but I think one must be careful then of relative URLS. For more info read Zope/lib/Components/ExtensionClass/Acquisition.stx in the Zope distribution. Pavlos
Pavlos Christoforou wrote:
On Tue, 2 Feb 1999, Michael Bernstein wrote:
If this is not currently possible, I would like to suggest that a 'context' attribute be added to <!-- #var -->, with the default being 'context=here' (the current behaviour) and an additional value of 'context=self' or perhaps 'context=origin' being made available.
Another possible value for a 'context' attribute might be 'context=parent' to move the context up one level in the hierarchy.
Lets suppose we have a document in the top level object named global_map with an entry like:
<A HREF="<!--# var title-->"><!--# var title--></A> <A HREF="<!--# var BASE1--><!--# var title-->"><!--# var title--></A>
How should the relative URL's or BASE variables be handled if this document is called from a subobject down the object hierarchy like <!--# var global_map context=origin--> ?
It should be handled exactly as if it were being called from the top level directory. Where this would break the functionality of the links, they should be constructed to create absolute URL's (as was discussed in another thread concerning image relative URL's). Please understand that I am not advocating changing the default behavior of zope, but only to add a little extra control into DTML. Michael.
Michael Bernstein wrote:
Pavlos Christoforou wrote:
On Tue, 2 Feb 1999, Michael Bernstein wrote:
If this is not currently possible, I would like to suggest that a 'context' attribute be added to <!-- #var -->, with the default being 'context=here' (the current behaviour) and an additional value of 'context=self' or perhaps 'context=origin' being made available.
<STUFF DELETED> How should the relative URL's or BASE variables be handled if this document is called from a subobject down the object hierarchy like <!--# var global_map context=origin--> ?
It should be handled exactly as if it were being called from the top level directory. Where this would break the functionality of the links, they should be constructed to create absolute URL's (as was discussed in another thread concerning image relative URL's).
Please understand that I am not advocating changing the default behavior of zope, but only to add a little extra control into DTML.
Ok, last chance for anyone to get their two cents in before I submit this as a feature request. If you feel this is a good/bad idea, or that I missed something crucial, let me know (privately if neccessary). Cheers, Michael.
At 01:59 PM 2/3/99 -0800, Michael Bernstein wrote:
Michael Bernstein wrote:
Pavlos Christoforou wrote:
On Tue, 2 Feb 1999, Michael Bernstein wrote:
If this is not currently possible, I would like to suggest that a 'context' attribute be added to <!-- #var -->, with the default being 'context=here' (the current behaviour) and an additional value of 'context=self' or perhaps 'context=origin' being made available.
<STUFF DELETED> How should the relative URL's or BASE variables be handled if this document is called from a subobject down the object hierarchy like <!--# var global_map context=origin--> ?
... Ok, last chance for anyone to get their two cents in before I submit this as a feature request. If you feel this is a good/bad idea, or that I missed something crucial, let me know (privately if neccessary).
Hmm. This request doesn't seem that clear to me. As I understand it, you want the ability to call methods on specific objects. If this is the case, why not use expressions: <!--#var expr="obj1.obj2.method()"--> rather than <!--#var method context="obj1.obj2"--> It's true that var does a little magic, so perhaps these constructs aren't exactly the same. But this doesn't seem like a big deal to me considering, you can do the magic with the special 'render' function: <!--#var expr="_.render(obj1.obj2.method)"--> If what you want with the 'context' option is an easy way to refer to the root object try this: <!--#var expr="PARENTS[-1]"--> So if you want to render a method, say 'global_map' in the context of the top-level object, try this: <!--#var expr="_.render(PARENTS[-1].global_map"--> Or do I misunderstand what you want to do? -Amos
On Wed, 3 Feb 1999, Amos Latteier wrote:
exactly the same. But this doesn't seem like a big deal to me considering, you can do the magic with the special 'render' function:
<!--#var expr="_.render(obj1.obj2.method)"-->
_.render ?? What else are you hiding? Pavlos
Amos Latteier wrote:
Hmm. This request doesn't seem that clear to me. As I understand it, you want the ability to call methods on specific objects. If this is the case, why not use expressions:
<!--#var expr="obj1.obj2.method()"-->
rather than
<!--#var method context="obj1.obj2"-->
It's true that var does a little magic, so perhaps these constructs aren't exactly the same. But this doesn't seem like a big deal to me considering, you can do the magic with the special 'render' function:
<!--#var expr="_.render(obj1.obj2.method)"-->
If what you want with the 'context' option is an easy way to refer to the root object try this:
<!--#var expr="PARENTS[-1]"-->
So if you want to render a method, say 'global_map' in the context of the top-level object, try this:
<!--#var expr="_.render(PARENTS[-1].global_map"-->
Or do I misunderstand what you want to do?
Here is a section of my original posting:
How can I control the context within which the various built in methods execute?
For example, I am using a tree tag in a document method to display subfolders in my global navigation. However, when this method is acquired by a subfolder, its context changes and it only lists the subfolders of the current folder. I want to force this method to execute within its original context in order to display the entire site structure regardless of the page being viewed.
In other words, I want to be able to force a method to render as if it had never been acquired. If the method is being acquired from the site root, 'context=origin' would force it to render within the context of the site root. However, if the method is being acquired from a sub-folder, it would force the method to render using the context of that sub-folder. I'm not quite sure that the code you posted isn't what I need, so forgive me if I'm restating the obvious. Thank you for your attention, Michael Bernstein.
participants (3)
-
Amos Latteier -
Michael Bernstein -
Pavlos Christoforou