[Zope] Acquisition: crazy idea

Paul Winkler pw_lists@slinkp.com
Fri, 25 Oct 2002 16:13:26 -0700


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