On Fri, 30 Jun 2000, Hamish Lawson wrote:
Jim Hebert wrote:
Is there a reason you can't do this by just messing with the namespaces stack, ie, adding additional folders to it?
I had been latterly thinking this myself and set about trying to do it, but being new to Zope development, didn't have much success! I presume it involves modifying the folders PARENTS list, but I wasn't quite sure how to do that.
Actually, I just used dtml-with. I'll go ahead and embarrass myself now, and explain what I did. Other people can chime in with "wow, that was dumb, here's the right way to do that" as needed (I'd really welcome that, actually!). My use was, I wanted to be able to pull in things like images, bits of text, whatever, from a "common" area but not have to litter, perceptually, the / area of my server. So, being someone used to idioms like -I/some/other/directory from the various glorified c-preprocessor "include" systems that I'd used on HTML in previous jobs, I set out to do that. =) So, for example, we have /images/ and there are Image objects in there. But I wanted to be able to just write <dtml-var foo_png> while working on pages, so I wrap the content with <dtml-with images> <dtml-with "PARENTS[0]"> ... </dtml-with> </dtml-with> The reason for the inner dtml-with is that my pages are DTML Methods, not DTML Documents, and the Folders are the "context." If all my content had "images" shoved on top of the namespaces stack, they'd get even simple things like <dtml-var title> wrong, because that's supposed to come from the Folder that method lives in... So, I push images onto the namespaces stack, then push "the parent" (as opposed to grandparent) up on top of the stack redundantly. This way the acquisition picks up the things like title from the current folder, and even lets the current folder override some of the "common" elements, but then falls back to this arbitrarily chosen folder to go find the other peices next, and then finally goes through the normal acquisition dance of going up the parents list. This actually worked out pretty well (boy, was I shocked ;->). HTH, jim -- Jim Hebert http://www.cosource.com/ jim@cosource.com The cooperative market for open source software "Well actually I was considering opening a market in flying pigs. Mostly because it would be more practical...." -- Alan Cox