Added a test for the first of three problems found in real life applications with the ViewPageTemplateFile

traversal.

from Explicit as well.

legacy attributes and they point to the right things.

be legacy implementations out there needing it.  Therefore we need to keep
our own ProviderExpression implementation.

Added legacy tests for content providers and viewlets

Minor cleanup.

support the Acquisition BBB (and __parent__ in order for it to work).

Use an explicit __init__ to work around problems with magically inserted super classes when using BrowserView as a base for viewlets.

Added hint on where the segfault happens. My test output is irritating, it seems we end up with a cyclic aq_chain again :(

behaviour of BrowserView.  Well, when I say failing I should really say
segfaulting :/

  class MyView(BrowserView):

      __call__ = ViewPageTemplateFile('...')

work.

support since Zope 2.10)

  class Foo:
      __call__ = SomeCallableObject()

This is very useful for Zope 3 templates where this paradigm is used
all over the place. In fact, mapply simply uses this part of Zope 3's
__call__ finding logic. (I actually wish we could simply switch over to
Zope 3's mapply, but the call signatures aren't the same. Sigh.)

implementation from Zope 3.

that the publishTraverse method on the Zope3 implementation, which we use now,
works as expected).

it with light shims over the Zope 3 stuff.

Moved special __parent__ behaviour up to the browserview class, so all classes inheriting from it, gain this special behavior.

browserDefault implementations that were returning object_thats_not_self, ()
didnt' work.