Evan Simpson wrote:
Chris Fassnacht wrote:
Wow. This is a fairly mind-blowing concept.
Isn't it, though? :-) This is part of why people talk about the "Zen of Zope".
You're saying I can pick and choose the stops I make on my way to an object and thereby create a unique collection of contexts (with their associated methods) that can be used to render the final object in the URL? So if I wanted the same information, say Info1, to be formatted for three different audiences, Aud1, Aud2, and Aud3, then I could (after writing the necessarily individualized methods for each audience) have three links like this: Root/Aud1/Info1, Root/Aud2/Info1, Root/Aud3/Info1, even though the containment hierarchy didn't actually reflect any of these URLs in its structure?
Exactly.
By the way, did you have any suggestions on my problem with getting a "multi-context" path (e.g., Root/Aud1/Info1 or Root.Aud1.Info1) out of a lines property and rendered using the looping construct you showed me earlier? I know it's something simple, but I can't find a helpful reference to it anywhere.
Mmf. If you *really* need to be able to specify arbitrary paths (there isn't some small collection of locations of interest?) then something like this should do it (I do recommend '/' as a path separator):
<dtml-call "REQUEST.set('targobj', Root)"> <dtml-in "_.string.split(path, '/')"> <dtml-call "REQUEST.set('targobj', _.getattr(targobj, _['sequence-item'])"> </dtml-in>
I'm not sure what your getting at here, but if you want to resolve a path to a URL try: <dtml-with "REQUEST.resolve_url((SCRIPT_NAME + '/path/to/object'))"> blah </dtml-with> -Michel