| Age | Commit message (Collapse) | Author |
|---|
|
directive. If this value is set, it must be an integer representing
the number of seconds which the auth tkt cookie will survive.
Mainly, its existence allows the auth_tkt cookie to survive across
browser sessions.
- The ``reissue_time`` argument to the ``authtktauthenticationpolicy``
ZCML directive now actually works. When it is set to an integer
value, an authticket set-cookie header is appended to the response
whenever a request requires authentication and 'now' minus the
authticket's timestamp is greater than ``reissue_time`` seconds.
- The router now checks for a ``global_response_headers`` attribute of
the request object before returning a response. If this value
exists, it is presumed to be a sequence of two-tuples, representing
a set of headers to append to the 'normal' response headers. This
feature is internal, rather than exposed internally, because it's
unclear whether it will stay around in the long term. It was added
to support the ``reissue_time`` feature of the authtkt
authentication policy.
- The ``authtkt`` authentication policy ``remember`` method now no
longer honors ``token`` or ``userdata`` keyword arguments.
|
|
|
|
|
|
decorator. In 1.1a7, it actually tried to grope every class in
scanned package at startup time looking for methods, which led to
some strange symptoms (e.g. ``AttributeError: object has no
attribute __provides__``). Now, instead of groping methods at
startup time, we just cause the ``bfg_view`` decorator itself to
populate its class' __dict__ when its used inside a class as a
method decorator. This is essentially a reversion back to 1.1a6
"grokking" behavior plus some special magic for using the
``bfg_view`` decorator as method decorator inside the ``bfg_view``
class itself.
|
|
used in ZCML) introduced in 1.1a7. Symptom: ``AttributeError:
object has no attribute __provides__`` raised at startup time.
|
|
|
|
|
|
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.
|
|
function populates a component registry from a ZCML file for testing
purposes.
|
|
predicates to ZCML view declaration, ZCML route declaration, and
``bfg_view`` decorator. See the ``Views`` narrative documentation
chapter for more information about these predicates.
|
|
following addtional attributes: ``attr``, ``renderer``, and
``wrapper``. These have the same meaning as they do in the context
of a ZCML ``view`` directive.
|
|
(orderings of views with predicates) were not evaluated in the
proper order. Symptom: in a configuration that had two views with
the same name but one with a ``request_method=POST`` predicate and
one without, the one without the predicate would be called
unconditionally (even if the request was a POST request). Thanks
much to Sebastien Douche for providing the buildbots that pointed
this out.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
generating URLs to static resources defined by the ``<static>`` ZCML
directive. See the "Views" narrative chapter's section titled
"Generating Static Resource URLs" for more information.
|
|
``view_renderer`` parameters (bring up to speed with 1.1a3
features). These can also be spelled as ``attr`` and ``renderer``.
|
|
deprecated in favor of
``repoze.bfg.testing.registerTemplateRenderer``. A deprecation
warning is *not* issued at import time for the former name; it will
exist "forever".
- The ``repoze.bfg.templating.renderer_from_cache`` function has been
moved to ``repoze.bfg.renderer.template_renderer_factory``. This
was never an API, but code in the wild was spotted that used it. A
deprecation warning is issued at import time for the former.
- Better error message when a wrapper view returns None.
|
|
|
|
required if the ZCML directive has a ``template`` attribute.
|
|
|
|
|
|
decorator) can now accept a "wrapper" value. If a "wrapper" value
is supplied, it is the value of a separate view's *name* attribute.
When a view with a ``wrapper`` attribute is rendered, the "inner"
view is first rendered normally. Its body is then attached to the
request as "wrapped_body", and then a wrapper view name is looked up
and rendered (using ``repoze.bfg.render_view_to_response``), passed
the request and the context. The wrapper view is assumed to do
something sensible with ``request.wrapped_body``, usually inserting
its structure into some other rendered template. This feature makes
it possible to specify (potentially nested) "owrap" relationships
between views using only ZCML or decorators (as opposed always using
ZPT METAL and analogues to wrap view renderings in outer wrappers).
|
|
decorator) can now accept an "attr" value. If an "attr" value is
supplied, it is considered a method named of the view object to be
called when the response is required. This is typically only good
for views that are classes or instances (not so useful for
functions, as functions typically have no methods other than
``__call__``).
- A ZCML ``view`` directive (and the associated ``bfg_view``
decorator) can now accept a "template" value. If a "template" value
is supplied, and the view callable returns a dictionary, the
associated template is rendered with the dictionary as keyword
arguments.
|
|
|
|
|
|
|
|
|
|
first argument ("root_dir") that represents a package-relative name
e.g. ``somepackage:foo/bar/static``. This is now the preferred
mechanism for spelling package-relative static paths using this
class. A ``package_name`` keyword argument has been left around for
backwards compatibility. If it is supplied, it will be honored.
- Fixed documentation for ``repoze.bfg.view.static`` (in narrative
``Views`` chapter).
|
|
|
|
a path, a name, and a factory instead of a name, a matcher, a
generator, and a factory.
|
|
without an ``environ_key`` directive (didn't match docs).
|
|
policies:
- ``repozewho1authenticationpolicy``
- ``remoteuserauthenticationpolicy``
- ``authtktauthenticationpolicy``
- Add a new ZCML directive which configures an ACL authorization
policy named ``aclauthorizationpolicy``.
|
|
|
|
pkg_resources provider only for modules which are known to have
overrides, instead of globally, when a <resource> directive is used
(performance).
|
|
function within ``templating`` to avoid needing to name the caller
module in resource overrides (actually match docs).
- Make it possible to override templates stored directly in a module
with templates in a subdirectory of the same module, stored directly
within another module, or stored in a subdirectory of another module
(actually match docs).
|
|
Rejigger error detection ordering.
|
|
|
|
|
|
of a route match would fail in a call to ``route.generate``.
|
|
|
|
attribute should refer to an interface or a class (ala the ``for``
attribute of the ``view`` ZCML directive).
|
|
IAuthenticationPolicy/IForbiddenView/INotFoundView based on older
concepts from the router module's ``make_app`` function into the
``repoze.bfg.zcml.zcml_configure`` callable, to service
compatibility with scripts that use "zope.configuration.xmlconfig"
(replace with ``repoze.bfg.zml.zcml_configure`` as necessary to get
BBB logic)
|
|
directive can be used to name a view that should be invoked when the
request can't otherwise be resolved to a view callable. For example::
<notfound
view="helloworld.views.notfound_view"/>
- A new ZCML directive was added named ``forbidden``. This ZCML
directive can be used to name a view that should be invoked when a
view callable for a request is found, but cannot be invoked due to
an authorization failure. For example::
<forbidden
view="helloworld.views.forbidden_view"/>
|
