Merge multiview2 branch to HEAD.

1 files changed, 122 insertions, 12 deletions

diff --git a/CHANGES.txt b/CHANGES.txt
index fc86ac5b6..5dd17f4a4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,117 @@
 Next release
 ============
 
+- The ``route`` ZCML directive now honors ``view_request_method``,
+  ``view_request_param`` and ``view_containment`` attributes, which
+  pass along these values to the associated view if any is provided.
+  Additionally, the ``request_type`` attribute can now be spelled as
+  ``view_request_type``, and ``permission`` can be spelled as
+  ``view_permission``.  Any attribute which starts with ``view_`` can
+  now be spelled without the ``view_`` prefix, so ``view_for`` can be
+  spelled as ``for`` now, etc.  Both forms are documented in the
+  urldispatch narraitve documentation chapter.
+
+- The ``request_param`` ZCML view directive attribute (and its
+  ``bfg_view`` decorator cousin) can now specify both a key and a
+  value.  For example, ``request_param="foo=123"`` means that the foo
+  key must have a value of ``123`` for the view to "match".
+
+- Bugfix: the ``discriminator`` for the ZCML "route" directive was
+  incorrect.  It was possible to register two routes that collided
+  without the system spitting out a ConfigurationConflictError at
+  startup time.
+
+- The ``static`` ZCML directive now uses a custom root factory when
+  constructing a route.
+
+- The ordering of route declarations vs. the ordering of view
+  declarations that use a "route_name" in ZCML no longer matters.
+  Previously it had been impossible to use a route_name from a route
+  that had not yet been defined in ZCML (order-wise) within a "view"
+  declaration.
+
+- The ``@bfg_view`` decorator now accepts three additional arguments:
+  ``request_method``, ``request_param``, and ``containment``.
+  ``request_method`` is used when you'd like the view to match only a
+  request with a particular HTTP ``REQUEST_METHOD``; a string naming
+  the ``REQUEST_METHOD`` can also be supplied as ``request_type`` for
+  backwards compatibility.  ``request_param`` is used when you'd like
+  a view to match only a request that contains a particular
+  ``request.params`` key (with or without a value).  ``containment``
+  is used when you'd like to match a request that has a context that
+  has some class or interface in its graph lineage.  These are
+  collectively known as "view predicates".
+
+- The interface ``IRequestFactories`` was removed from the
+  repoze.bfg.interfaces module.  This interface was never an API.
+
+- The interfaces ``IPOSTRequest``, ``IGETRequest``, ``IPUTRequest``,
+  ``IDELETERequest``, and ``IHEADRequest`` have been removed from the
+  ``repoze.bfg.interfaces`` module.  These were not documented as APIs
+  post-1.0.  Instead of using one of these, use a ``request_method``
+  ZCML attribute or ``request_method`` bfg_view decorator parameter
+  containing an HTTP method name (one of ``GET``, ``POST``, ``HEAD``,
+  ``PUT``, ``DELETE``) instead of one of these interfaces if you were
+  using one explicitly.  Passing a string in the set (``GET``,
+  ``HEAD``, ``PUT``, ``POST``, ``DELETE``) as a ``request_type``
+  argument will work too.  Rationale: instead of relying on interfaces
+  attached to the request object, BFG now uses a "view predicate" to
+  determine the request type.
+
+- The function named ``named_request_factories`` and the data
+  structure named ``DEFAULT_REQUEST_FACTORIES`` have been removed from
+  the ``repoze.bfg.request`` module.  These were never APIs.
+
+- Feature addition: view predicates.  These are exposed as the
+  ``request_method``, ``request_param``, and ``containment``
+  attributes of a ZCML ``view`` declaration, or the respective
+  arguments to a ``@bfg_view`` decorator.  View predicates can be used
+  to register a view for a more precise set of environment parameters
+  than was previously possible.  For example, you can register two
+  views with the same ``name`` with different ``request_param``
+  attributes.  If the ``request.params`` dict contains 'foo'
+  (request_param="foo"), one view might be called; if it contains
+  'bar' (request_param="bar"), another view might be called.
+  ``request_param`` can also name a key/value pair ala ``foo=123``.
+  This will match only when the ``foo`` key is in the request.params
+  dict and it has the value '123'.  This particular example makes it
+  possible to write separate view functions for different form
+  submissions.  The other predicates, ``containment`` and
+  ``request_method`` work similarly.  ``containment`` is a view
+  predicate that will match only when the context's graph lineage has
+  an object possessing a particular class or interface, for example.
+  ``request_method`` is a view predicate that will match when the HTTP
+  ``REQUEST_METHOD`` equals some string (eg. 'POST').
+
+- The repoze.bfg router now catches both
+  ``repoze.bfg.security.Unauthorized`` and
+  ``repoze.bfg.view.NotFound`` exceptions while rendering a view.
+  When the router catches an ``Unauthorized``, it returns the
+  registered forbidden view.  When the router catches a ``NotFound``,
+  it returns the registered notfound view.
+
+- Custom ZCML directives which register an authentication or
+  authorization policy (ala "authtktauthenticationpolicy" or
+  "aclauthorizationpolicy") should register the policy "eagerly" in
+  the ZCML directive instead of from within a ZCML action.  If an
+  authentication or authorization policy is not found in the component
+  registry by the view machinery during deferred ZCML processing, view
+  security will not work as expected.
+
+- The API ``repoze.bfg.testing.registerViewPermission`` has been
+  deprecated.
+
+- The API ``repoze.bfg.testing.registerView`` now takes a
+  ``permission`` argument.  Use this instead of using
+  ``repoze.bfg.testing.registerViewPermission``.
+
+- Removed ViewPermissionFactory from ``repoze.bfg.security``.  View
+  permission checking is now done by registering and looking up an
+  ISecuredView.
+
+- Views registered without the help of the ZCML ``view`` directive are
+  now responsible for performing their own authorization checking.
+
 - The ``repoze.bfg.view.static`` class now accepts a string as its
   first argument ("root_dir") that represents a package-relative name
   e.g. ``somepackage:foo/bar/static``.  This is now the preferred
@@ -975,12 +1086,12 @@ Features
   policy defaults to an authorization implementation that uses ACLs
   (``repoze.bfg.authorization.ACLAuthorizationPolicy``).
 
-  .. note:: we no longer encourage configuration of "security
-    policies" using ZCML, as previously we did for
-    ``ISecurityPolicy``.  This is because it's not uncommon to need to
-    configure settings for concrete authorization or authentication
-    policies using paste .ini parameters; the app entry point for your
-    application is the natural place to do this.
+  We no longer encourage configuration of "security policies" using
+  ZCML, as previously we did for ``ISecurityPolicy``.  This is because
+  it's not uncommon to need to configure settings for concrete
+  authorization or authentication policies using paste .ini
+  parameters; the app entry point for your application is the natural
+  place to do this.
 
 - Two new abstractions have been added in the way of adapters used by
   the system: an ``IAuthorizationPolicy`` and an
@@ -1387,9 +1498,8 @@ Features
   source at installation time.  In particular, ``repoze.bfg`` no
   longer depends on the ``lxml`` package.
 
-  .. note:: this change has introduced some backwards
-            incompatibilities, described in the "Backwards
-            Incompatibilities" section below.
+  This change has introduced some backwards incompatibilities,
+  described in the "Backwards Incompatibilities" section below.
 
 - This release was tested on Windows XP.  It appears to work fine and
   all the tests pass.
@@ -1565,7 +1675,7 @@ Backwards Incompatibilities
   opposed to URL-dispatch), and the root object supplied
   the``repoze.bfg.interfaces.ILocation`` interface, but the children
   returned via its ``__getitem__`` returned an object that did not
-  implement the same interface, :mod:`repoze.bfg` provided some
+  implement the same interface, ``repoze.bfg`` provided some
   implicit help during traversal.  This traversal feature wrapped
   subobjects from the root (and thereafter) that did not implement
   ``ILocation`` in proxies which automatically provided them with a
@@ -1815,7 +1925,7 @@ Features
 
 - "Virtual root" support for traversal-based applications has been
   added.  Virtual root support is useful when you'd like to host some
-  model in a :mod:`repoze.bfg` model graph as an application under a
+  model in a ``repoze.bfg`` model graph as an application under a
   URL pathname that does not include the model path itself.  For more
   information, see the (new) "Virtual Hosting" chapter in the
   documentation.
@@ -1854,7 +1964,7 @@ Features
 --------
 
 - You can now override the NotFound and Unauthorized responses that
-  :mod:`repoze.bfg` generates when a view cannot be found or cannot be
+  ``repoze.bfg`` generates when a view cannot be found or cannot be
   invoked due to lack of permission.  See the "ZCML Hooks" chapter in
   the docs for more information.