| Age | Commit message (Collapse) | Author |
|---|
|
a context.
Cause append_slash_notfound_view to work in case it is registered via
set_notfound_view.
|
|
|
|
Add debug_templates setting.
|
|
weirdness (finding nonminimal.txt.py).
|
|
$REPOZE_SVN/repoze.bfg/branches/i18n
No foreigners were harmed in the coding of this feature.
|
|
merge -r9054:9030 svn+ssh://repoze@svn.repoze.org/svn/repoze.bfg/trunk
|
|
Make get_translation always return something.
|
|
|
|
|
|
|
|
<http://docs.repoze.org/venusian>`) to perform ``bfg_view``
decorator scanning rather than relying on a BFG-internal decorator
scanner. (Truth be told, Venusian is really just a generalization
of the BFG-internal decorator scanner).
- A new install-time dependency on the ``venusian`` distribution was
added.
- Remove ``repoze.bfg.compat.pkgutil_26.py`` and import alias
``repoze.bfg.compat.walk_packages``. These were only required by
internal scanning machinery; Venusian replaced the internal scanning
machinery, so these are no longer required.
|
|
the "phash" branch.
|
|
o http://bugs.repoze.org/issue138
|
|
Coverage.
|
|
prepended a fully-expanded urldispatch route URL before a the
model's path if it was noticed that the request had matched a route.
This feature was ill-conceived, and didn't work in all scenarios.
|
|
specification values (internal).
|
|
decorator that provided a package-relative template filename might
not have been resolved properly. Symptom: inappropriate ``Missing
template resource`` errors.
|
|
that named a view callable and also a ``view_attr`` became broken.
Symptom: ``MyViewClass is not callable`` or the ``__call__`` of a
class was being called instead of the method named via
``view_attr``.
|
|
---------
- Ensure that ``secure`` flag for AuthTktAuthenticationPolicy
constructor does what it's documented to do (merge Daniel Holth's
fancy-cookies-2 branch).
New Features
------------
- Add ``path`` and ``http_only`` options to
AuthTktAuthenticationPolicy constructor (merge Daniel Holth's
fancy-cookies-2 branch).
|
|
``view_path_info``, ``view_request_method``, ``view_request_param``,
and ``view_containment`` predicate arguments from the
``Configurator.add_route`` argument list. These arguments were
speculative. If you need the features exposed by these arguments,
add a view associated with a route using the ``route_name`` argument
to the ``add_view`` method instead.
- Remove ``view_header``, ``view_accept``, ``view_xhr``,
``view_path_info``, ``view_request_method``, ``view_request_param``,
and ``view_containment`` predicate arguments from the ``route`` ZCML
directive attribute set. These attributes were speculative. If you
need the features exposed by these attributes, add a view associated
with a route using the ``route_name`` attribute of the ``view`` ZCML
directive instead.
|
|
|
|
|
|
|
|
|
|
|
|
of predicates registered first (literally first, not "earlier") for
a triad would lose during view lookup to one registered with fewer.
|
|
http://labs.creativecommons.org/2010/01/13/cc-engine-and-web-non-frameworks/ .. can't seem to repeat.
|
|
the class attribute named ``charset`` within
``repoze.bfg.request.Request``. BFG now *requires* WebOb >= 0.9.7,
and code was added so that this deprecation warning has disappeared.
|
|
---------
- When the ``Configurator`` is passed an instance of
``zope.component.registry.Components`` as a ``registry`` constructor
argument, fix the instance up to have the attributes we expect of an
instance of ``repoze.bfg.registry.Registry`` when ``setup_registry``
is called. This makes it possible to use the global Zope component
registry as a BFG application registry.
Documentation
-------------
- Change renderings of ZCML directive documentation.
- Add a narrative documentation chapter: "Using the Zope Component
Architecture in ``repoze.bfg``"
|
|
|
|
--------
- The ``Configurator.add_view`` method now accepts an argument named
``context``. This is an alias for the older argument named
``for_``; it is preferred over ``for_``, but ``for_`` will continue
to be supported "forever".
- The ``view`` ZCML directive now accepts an attribute named
``context``. This is an alias for the older attribute named
``for``; it is preferred over ``for``, but ``for`` will continue to
be supported "forever".
- The ``Configurator.add_route`` method now accepts an argument named
``view_context``. This is an alias for the older argument named
``view_for``; it is preferred over ``view_for``, but ``view_for``
will continue to be supported "forever".
- The ``route`` ZCML directive now accepts an attribute named
``view_context``. This is an alias for the older attribute named
``view_for``; it is preferred over ``view_for``, but ``view_for``
will continue to be supported "forever".
Documentation and Paster Templates
----------------------------------
- All uses of the ``Configurator.add_view`` method that used its
``for_`` argument now use the ``context``argument instead.
- All uses of the ``Configurator.add_route`` method that used its
``view_for`` argument now use the ``view_context``argument instead.
- All uses of the ``view`` ZCML directive that used its ``for``
attribute now use the ``context`` attribute instead.
- All uses of the ``route`` ZCML directive that used its ``view_for``
attribute now use the ``view_context`` attribute instead.
|
|
Small stylistic change in old-view detection.
|
|
I've committed a patch for on a branch.
|
|
early 1.2 alpha) was deprecated. Its import now generates a
deprecation warning.
- Docs roles.
|
|
API.
- Add roles to configurator API docs.
|
|
``application/json``. It now does, by setting
``request.response_content_type`` unless this attribute is already
set.
- The ``string`` renderer failed to set the response content type to
``text/plain``. It now does, by setting
``request.response_content_type`` unless this attribute is already
set.
|
|
|
|
and config.registry.registerUtility will work).
|
|
``repoze.bfg.configuration.Configurator`` class:
``testing_securitypolicy``, ``testing_models``,
``testing_add_subscriber``, and ``testing_add_template``. These
were added in order to provide more direct access to the
functionality of the ``repoze.bfg.testing`` APIs named
``registerDummySecurityPolicy``, ``registerModels``,
``registerEventListener``, and ``registerTemplateRenderer`` when a
configurator is used. The ``testing`` APIs named are nominally
deprecated (although they will likely remain around "forever", as
they are in heavy use in the wild).
- Doc-deprecated most helper functions in the ``repoze.bfg.testing``
module. These helper functions likely won't be removed any time
soon, nor will they generate a warning any time soon, due to their
heavy use in the wild, but equivalent behavior exists in methods of
a Configurator.
|
|
class: ``add_settings``. This API can be used to add "settings"
(information returned within via the
``repoze.bfg.settings.get_settings`` API) after the configurator has
been initially set up. This is most useful for testing purposes.
|
|
class: ``add_adapter`` and ``add_utility``. These, respectively,
perform the same functions as the ``registerAdapter`` and
``registerUtility`` functions of a ZCA registry. They were added to
allow for a more consistent testing API for applications that make
use of the ZCA directly.
- Cause the ``adapter``, ``utility``, and ``subscriber`` ZCML
directives to use a ``Configurator`` instance and associated
configurator APIs rather than a ZCA registry directly.
|
|
``add_view`` method, the ``bfg_view`` decorator and the attribute
list of the ZCML ``view`` directive. If ``custom_predicates`` is
specified, it must be a sequence of predicate callables (a predicate
callable accepts two arguments: ``context`` and ``request`` and
returns ``True`` or ``False``). The associated view callable will
only be invoked if all custom predicates return ``True``. Use one
or more custom predicates when no existing predefined predicate is
useful. Predefined and custom predicates can be mixed freely.
- Add a ``custom_predicates`` argument to the ``Configurator``
``add_route`` and the attribute list of the ZCML ``route``
directive. If ``custom_predicates`` is specified, it must be a
sequence of predicate callables (a predicate callable accepts two
arguments: ``context`` and ``request`` and returns ``True`` or
``False``). The associated route will match will only be invoked if
all custom predicates return ``True``, else route matching
continues. Use one or more custom predicates when no existing
predefined predicate is useful. Predefined and custom predicates
can be mixed freely.
|
|
--------
- The ``Configurator`` object now has two new methods: ``begin`` and
``end``. The ``begin`` method is meant to be called before any
"configuration" begins (e.g. before ``add_view``, et. al are
called). The ``end`` method is meant to be called after all
"configuration" is complete.
Previously, before there was imperative configuration at all (1.1
and prior), configuration begin and end was invariably implied by
the process of loading a ZCML file. When a ZCML load happened, the
threadlocal data structure containing the request and registry was
modified before the load, and torn down after the load, making sure
that all framework code that needed ``get_current_registry`` for the
duration of the ZCML load was satisfied.
Some API methods called during imperative configuration, (such as
``Configurator.add_view`` when a renderer is involved) end up for
historical reasons calling ``get_current_registry``. However, in
1.2a5 and below, the Configurator supplied no functionality that
allowed people to make sure that ``get_current_registry`` returned
the registry implied by the configurator being used. ``begin`` now
serves this purpose. Inversely, ``end`` pops the thread local
stack, undoing the actions of ``begin``.
We make this boundary explicit to reduce the potential for confusion
when the configurator is used in different circumstances (e.g. in
unit tests and app code vs. just in initial app setup).
Existing code written for 1.2a1-1.2a5 which does not call ``begin``
or ``end`` continues to work in the same manner it did before. It
is however suggested that this code be changed to call ``begin`` and
``end`` to reduce the potential for confusion in the future.
- All ``paster`` templates which generate an application skeleton now
make use of the new ``begin`` and ``end`` methods of the
Configurator they use in their respective copies of ``run.py`` and
``tests.py``.
Documentation
-------------
- All documentation that makes use of a ``Configurator`` object to do
application setup and test setup now makes use of the new ``begin``
and ``end`` methods of the configurator.
Bug Fixes
---------
- When a ``repoze.bfg.exceptions.NotFound`` or
``repoze.bfg.exceptions.Forbidden`` *class* (as opposed to instance)
was raised as an exception within a root factory (or route root
factory), the exception would not be caught properly by the
``repoze.bfg.`` Router and it would propagate to up the call stack,
as opposed to rendering the not found view or the forbidden view as
would have been expected.
|
|
``Configurator.add_view`` or some derivative), they too-eagerly
attempted to look up the ``reload_templates`` setting via
``get_settings``, meaning they were always registered in
non-auto-reload-mode (the default). Each now waits until its
respective ``template`` attribute is accessed to look up the value.
|
|
---------
- When a route with the same name as a previously registered route was
added, the old route was not removed from the mapper's routelist.
Symptom: the old registered route would be used (and possibly
matched) during route lookup when it should not have had a chance to
ever be used.
|
|
documentation chapter explaining the effect of raising
``repoze.bfg.exceptions.NotFound`` and
``repoze.bfg.exceptions.Forbidden`` from within view code.
- When the ``repoze.bfg.exceptions.NotFound`` or
``repoze.bfg.exceptions.Forbidden`` error is raised from within a
custom root factory or the ``factory`` of a route, the appropriate
response is now sent to the requesting user agent (the result of the
notfound view or the forbidden view, respectively). When these
errors are raised from within a root factory, the ``context`` passed
to the notfound or forbidden view will be ``None``. Also, the
request will not be decorated with ``view_name``, ``subpath``,
``context``, etc. as would normally be the case if traversal had
been allowed to take place.
|
|
``setup.py`` ``tests_require`` argument (Twill will only be
downloaded when :mod:`repoze.bfg` ``setup.py test`` or ``setup.py
nosetests`` is invoked).
|
|
of a ``Configurator`` is now importable as
``repoze.bfg.exceptions.ConfigurationError``.
|
|
|
|
``repoze.bfg.configuration`` module began to attempt to import the
``repoze.bfg.chameleon_zpt`` and ``repoze.bfg.chameleon_text``
modules, and these cannot be used on non-CPython platforms. It now
tolerates startup time import failures for these modules, and only
raise an import error when a template from one of these packages is
actually used.
|
