[Zope-dev] AttributeError validate using the Visitor pattern

[R. David Murray]

OK, having helped me figure out how to work around the bug in accessing
ZPatterns objects from a catalog, I've got a new challenge for you all.

Now that I've got my list of objects, I want to generate a web page displaying
them.  The page has the structure of a series of table rows.  Inside each
row data about a single object is displayed, using a common format but
with certain differences depending on the type of object.  To implement this,
I am trying to use the Visitor pattern from the Gang of Four book.

So, I have a Folder displayItemList.  This folder contains (at the moment)
three methods: displayTable, visitAuthor, and visitBook.  displayTable
generates the html for the outer table, down to the <tr></tr> tags.
Between those tags, it calls <dtml-var "accept(me)">, where me is
this() for the displayTable method, and accept is a pythonscript method
defined on each of the object type's Specialist.  Each accept method
is of the form:

return visitor.visitBook(None,_,item=context)

with _ bound to namespace on the bindings tab and 'visitor' being listed
in the arguments line.

visitBook begins with the line:

<dtml-with item>

Trying to display my list, I get an AttributeError on 'validate', and
ZDebug flags the 'with' line as the error location.  validate
appears nowhere in my code, so from all I can figure from a certain
amount of inspection of the source, Zope is looking for this method
on the DTMLMethod and not finding it.

ZDebug says the namespace stack consists of a single entry, which looks like
the DTMLMethod itself (visitBook, presumably).  Seems to me the namespace
stack should be deeper than that.

I've been poking at this for a couple hours now without making any more
progress, so I'm going to quit for the day and come back to it tomorrow.
If anybody has any bright ideas, or sees something obvious I'm doing wrong,
please clue me in.  Thanks!

By the way, I also tried making accept be visitor.visitBook(context,_),
but that produced the same error and ZDebug could only point to the
call to accept as the error location.

--RDM