from webob import Response
    from repoze.bfg.view import bfg_view

    class MyView(object):
        def __init__(self, context, request):
            self.context = context
            self.request = request

        @bfg_view(name='hello')
        def amethod(self):
            return Response('hello from %s!' % self.context)

  When the bfg_view decorator is used against a class method, a view
  is registered for the *class* (it's a "class view" where the "attr"
  happens to be the method they're attached to), so the view class
  must have a suitable constructor.

  any number of others.  Each invocation of the decorator registers a
  single view.  For instance, the following combination of decorators
  and a function will register two views::

    from repoze.bfg.view import bfg_view

    @bfg_view(name='edit')
    @bfg_view(name='change')
    def edit(context, request):
        pass

  This makes it possible to associate more than one view configuration
  for a single callable without requiring ZCML.

  This should have no external effects.

- An object implementing the ``IRenderer`` interface (and
  ``ITemplateRenderer`, which is a subclass of ``IRenderer``) must now
  accept an extra ``system`` argument in its ``__call__`` method
  implementation.  Values computed by the system (as opposed to by the
  view) are passed by the system in the ``system`` parameter, which
  will always be a dictionary.  Keys in the dictionary include:
  ``view`` (the view object that returned the value),
  ``renderer_name`` (the template name or simple name of the
  renderer), ``context`` (the context object passed to the view), and
  ``request`` (the request object passed to the view).  Previously
  only ITemplateRenderers received system arguments as elements inside
  the main ``value`` dictionary.

  via use of the ``bfg_view`` decorator in Python 2.6 as a class
  decorator).  The calling semantics when using a class as a view
  callable is similar to that of using a class as a Zope "browser
  view": the class' ``__init__`` must accept two positional parameters
  (conventionally named ``context``, and ``request``).  The resulting
  instance must be callable (it must have a ``__call__`` method).
  When called, the instance should return a response.  For example::

    from webob import Response

    class MyView(object):
        def __init__(self, context, request):
            self.context = context
            self.request = request

        def __call__(self):
            return Response('hello from %s!' % self.context)

   See the "Views" chapter in the documentation and the
   ``repoze.bfg.view`` API documentation for more information.

--------

- The functionality of ``repoze.bfg.convention`` has been merged into
  the core.  Applications which make use of ``repoze.bfg.convention``
  will continue to work indefinitely, but it is recommended that apps
  stop depending upon it.  To do so, substitute imports of
  ``repoze.bfg.convention.bfg_view`` with imports of
  ``repoze.bfg.view.bfg_view``, and change the stanza in ZCML from
  ``<convention package=".">`` to ``<grok package=".">``.  As a result
  of the merge, bfg has grown a new dependency: ``martian``.

- View functions which use the pushpage decorator are now pickleable
  (meaning their use won't prevent a ``configure.zcml.cache`` file
  from being written to disk).

Implementation Changes
----------------------

- The ``wsgiapp`` decorator now uses ``webob.Request.get_response`` to
  do its work rather than relying on howgrown WSGI code.