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