| Age | Commit message (Collapse) | Author |
|---|
|
|
|
absolute filesystem path including a drive letter was passed as
``filename`` (or as ``configure_zcml`` in the options dict) to
``repoze.bfg.router.make_app``, it would be treated as a
package:resource_name specification.
|
|
bfgwiki2 (urldispatch+SA) tutorials.
- Use bfgsite index for all tutorial setup.cfg files.
|
|
|
|
Use request.url as "referrer" as we're no longer redirecting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
explains how to extend or modify an existing BFG application using
another Python package and ZCML.
|
|
|
|
explains how to override resources within one package from another
package.
|
|
environment variable (``BFG_CONFIGURE_ZCML``) to name a ZCML file
that will be used to bootstrap the application. Previously, the
integrator could not influence which ZCML file was used to do the
boostrapping (only the original application developer could do so).
|
|
|
|
|
|
|
|
|
|
"package_name:relative/path" to APIs like ``render_template``,
``render_template_to_response``, and ``get_template``. Sometimes
the package in which a caller lives is a direct namespace package,
so the module which is returned is semi-useless for navigating from.
|
|
|
|
|
|
|
|
arguments to ``repoze.bfg.router.make_app``. Instead, developers
should use the various authentication policy ZCML directives
(``repozewho1authenticationpolicy``,
``remoteuserauthenticationpolicy`` and
``authtktauthenticationpolicy``) and the `aclauthorizationpolicy``
authorization policy directive as described in the changes to the
"Security" narrative documentation chapter and the wiki tutorials.
|
|
policies:
- ``repozewho1authenticationpolicy``
- ``remoteuserauthenticationpolicy``
- ``authtktauthenticationpolicy``
- Add a new ZCML directive which configures an ACL authorization
policy named ``aclauthorizationpolicy``.
|
|
|
|
|
|
|
|
|
|
instantiated, and the package it was overriding already had a
``__loader__`` attribute, it would fail at startup time, even if the
``__loader__`` attribute was another PackageOverrides instance. We
now replace any ``__loader__`` that is also a PackageOverrides
instance. Symptom: ``ConfigurationExecutionError: <type
'exceptions.TypeError'>: Package <module 'karl.views' from
'/Users/chrism/projects/osi/bfgenv/src/karl/karl/views/__init__.pyc'>
already has a __loader__ (probably a module in a zipped egg)``.
|
|
|
|
|
|
``BFG_RELOAD_RESOURCES`` environment variable). When this is set to
true, the server never needs to be restarted when moving files
between directory resource overrides (esp. for templates currently).
- Add a ``reload_all`` configuration file setting (aka the
``BFG_RELOAD_ALL`` environment variable) that implies both
``reload_resources`` and ``reload_templates``.
- The ``static`` helper view class now uses a ``PackageURLParser`` in
order to allow for the overriding of static resources (CSS / logo
files, etc) using the ``resource`` ZCML directive. The
``PackageURLParser`` class was added to a (new) ``static`` module in
BFG; it is a subclass of the ``StaticURLParser`` class in
``paste.urlparser``.
- The ``repoze.bfg.templating.renderer_from_cache`` function now
checks for the ``reload_resources`` setting; if it's true, it does
not register a template renderer (it won't use the registry as a
template renderer cache).
- Add ``pkg_resources`` to the glossary.
- Update the "Environment" docs to note the existence of
``reload_resources`` and ``reload_all``.
- Use a colon instead of a tab as the separator between package name
and relpath to form the "spec" when register a ITemplateRenderer.
|
|
- The view on the root shows a list of links to records.
- The view on a record shows the details for that object.
|
|
|
|
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).
|
|
|
|
|
