History for FakePublish

??changed:
-
I find myself getting frustrated with trying to find where things
are in the ZODB of a project that I'm working on. I'm working with
other developers, and even though we're consistent and sensible
enough about design, there are several places to hunt for what
is publishing something - normal containment on the ZODB filesystem,
ZClass methods, and Python methods, with acquisition meaning that
the URL isn't very helpful for locating something.  When the Zope
installation is 3000 miles away from my box & guarded by slow
connectivity, slogging through several browser windows takes up
too much time.

The only way to fly is to use the monitor or the debugger.  See
<a href=
"http://www.zope.org/Members/michel/HowTos/TheDebuggerIsYourFriend">
The Debugger Is Your Friend</a> and
<a href="http://www.zope.org/Documentation/Misc/DEBUGGING.txt">
Zope Deugging</a>.

In order to see how something is published, we have to follow the process that the publisher takes.  I stepped through the code and saw that the action (for my current Zope checkout, 2.2.x) is in

 - /lib/python/ZPublisher/Publish.py(122)publish()

 - /lib/python/ZPublisher/BaseRequest.py(224)traverse()

but that doesn't help much.  Almost everything is published by
walking from the root to the leaf and, for each parent, calling
getattr(parent, child)
to get the child.  If that doesn't work, we try
!parent[child]
And we also look for a __bobo_traverse__ method, & try specific things
at the end, like the default index_html attribute and calling the final
object.  getattr is overridden in a C extension, which
I wasn't prepared to decipher.  But, we can short-circuit acquisition,
and find out if something is a method or a containee, and
emulate the publishing process well enough that way.

Here's what I use - I call it from the monitor:

- FakePublishCode

It basically
saves me from typing in the tests to find something:

- get the object from its URL by converting slashes to dots

- get a path to the object that it's acquired from by calling
  object.getPhysicalPath() on it, which returns a list
  of objects in the acquisition base's path

- each subset [0:i] of this list gets us a parent object with
  unrestrictedTraverse().  For each of these objects, we
  want to know its relation to the child:

  - if the child isn't an attribute of the parent, it's reached by
    __bobo_traverse__ or some other complex method, and we'll
    have to be more thorough than this hack

  - else, if the child is in dir(parent), it's simple
    containment.

  - else, if the child is in the dictionary of the class of the
    parent, it's a method of a ZClass or Python class.

It's not complete, but it saves time.  I still have to find out if
a parent is a ZClass or a Python product.

If the parent is a ZClass and the child is a method, I'd like to
spit out an URL for that method so I can feed it to my browser,
but I don't know if that's possible.