Does everybody remember their early days of using ZOpe when you probably tried top/ images/ bar.gif foo/ index_html images/ ... and then in top/foo/index_html you put: <dtml-var "images['bar.gif']> ... and were thus introduced to the joy and pain of grokking acquisition? Well, I was discussing this with a coworker today (he's an experienced jsp developer, but new to zope) and he said well, why *doesn't* that work, and I didn't have a good answer. What if there were an (optional?) extension to the acquisition rules such that, if the current acquisition process finishes and no object is found, we try to to replace the aq_parent with the next object of the same id found further up the acquisition chain? And then do this recursively back up the acquisition chain until finally we run out of places to look? So instead of saying "I found images/ but it doesn't contain bar.gif', zope would say "hmm, I didn't find what I wanted, there's no bar.gif in here, let me go looking for another images/ and try again." def recursively_rewrap_and_look_again(self, attrname): try: self.aq_chain[1] ... # get the object we would have found # if the current self.aq_chain[1] did not exist except IndexError: raise NotFound # I have no aq_parents, there's nowhere else to look try: return getattr(self, attrname) except AttributeError: new_me = self.aq_chain[1].recursively_rewrap_and_look_again(self.id) return getattr(new_me, attrname) ... uh... or something like that. :) I feel like this must have nasty implications, but I can't see what, except that I have no clue how "get the object we would have found" would work. -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"