| Age | Commit message (Collapse) | Author |
|---|
|
|
|
a request object, instead of both a context and a request (which
still works, and always will). The following types work as views in
this style:
- functions that accept a single argument ``request``, e.g.::
def aview(request):
pass
- new and old-style classes that have an ``__init__`` method that
accepts ``self, request``, e.g.::
def View(object):
__init__(self, request):
pass
- Arbitrary callables that have a ``__call__`` method that accepts
``self, request``, e.g.::
def AView(object):
def __call__(self, request):
pass
view = AView()
This likely should have been the calling convention all along, as
the request has ``context`` as an attribute already, and with views
called as a result of URL dispatch, having the context in the
arguments is not very useful. C'est la vie.
|
|
|
|
alias for its ``condition_method`` argument for symmetry with the
``view`` directive.
|
|
``bfg_view`` decorators can now be one of the strings ``GET``,
``POST``, ``PUT``, ``DELETE``, or ``HEAD`` instead of a reference to
the respective interface type imported from
``repoze.bfg.interfaces``.
|
|
|
|
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.
|
|
|
|
``configure.zcml.cache`` next to ``configure.zcml`` files in
projects). The code which managed writing and reading of the cache
file was a source of subtle bugs when users switched between
imperative (e.g. ``@bfg_view``) registrations and declarative
registrations (e.g. the ``view`` directive in ZCML) on the same
project. On a moderately-sized project (535 ZCML actions and 15 ZCML
files), executing actions read from the pickle was saving us only
about 200ms (2.5 sec vs 2.7 sec average). On very small projects (1
ZCML file and 4 actions), startup time was comparable, and sometimes
even slower when reading from the pickle, and both ways were so fast
that it really just didn't matter anyway.
|
|
removed, as well as its documentation. It had been deprecated since
0.6.3. Code in ``repoze.bfg.urldispatch.RoutesModelTraverser``
which catered to it has also been removed.
- The semantics of the ``route`` ZCML directive have been simplified.
Previously, it was assumed that to use a route, you wanted to map a
route to an externally registered view. The new ``route`` directive
instead has a ``view`` attribute which is required, specifying the
dotted path to a view callable. When a route directive is
processed, a view is *registered* using the name attribute of the
route directive as its name and the callable as its value. The
``view_name`` and ``provides`` attributes of the ``route`` directive
are therefore no longer used. Effectively, if you were previously
using the ``route`` directive, it means you must change a pair of
ZCML directives that look like this::
<route
name="home"
path=""
view_name="login"
factory=".models.root.Root"
/>
<view
for=".models.root.Root"
name="login"
view=".views.login_view"
/>
To a ZCML directive that looks like this::
<route
name="home"
path=""
view=".views.login_view"
factory=".models.root.Root"
/>
In other words, to make old code work, remove the ``view``
directives that were only there to serve the purpose of backing
``route`` directives, and move their ``view=`` attribute into the
``route`` directive itself.
This change also necessitated that the ``name`` attribute of the
``route`` directive is now required. If you were previously using
``route`` directives without a ``name`` attribute, you'll need to
add one (the name is arbitrary, but must be unique among all
``route`` and ``view`` statements).
The ``provides`` attribute of the ``route`` directive has also been
removed. This directive specified a sequence of interface types
that the generated context would be decorated with. Since route
views are always generated now for a single interface
(``repoze.bfg.IRoutesContext``) as opposed to being looked up
arbitrarily, there is no need to decorate any context to ensure a
view is found.
- The Routes ``Route`` object used to resolve the match is now put
into the environment as ``bfg.route`` when URL dispatch is used.
|
|
|
|
|
|
|
|
context_interfaces -> provides
|
|
|
|
|
|
--------
- 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.
|
|
|
|
``zope.component.interface.provideInterface`` for the ``for``
interface. We don't support ``provideInterface`` in BFG because
it mutates the global registry.
|
|
|
|
- Rather than prepare the "stock" implementations of the ZCML
directives from the ``zope.configuration`` package for use under
:mod:`repoze.bfg`, :mod:`repoze.bfg` now makes available the
implementations of directives from the ``repoze.zcml`` package
(see http://static.repoze.org/zcmldocs). As a result, the
:mod:`repoze.bfg` package now depends on the ``repoze.zcml``
package, and no longer depends directly on the ``zope.component``,
``zope.configuration``, ``zope.interface``, or ``zope.proxy``
packages.
The primary reason for this change is to enable us to eventually
reduce the number of inappropriate :mod:`repoze.bfg` Zope package
dependencies, as well as to shed features of dependent package
directives that don't make sense for :mod:`repoze.bfg`.
Note that currently the set of requirements necessary to use bfg
has not changed. This is due to inappropriate Zope package
requirements in ``chameleon.zpt``, which will hopefully be
remedied soon.
- BFG applications written prior to this release which expect the
"stock" ``zope.component`` ZCML directive implementations
(e.g. ``adapter``, ``subscriber``, or ``utility``) to function now
must either 1) include the ``meta.zcml`` file from
``zope.component`` manually (e.g. ``<include
package="zope.component" file="meta.zcml">``) and include the
``zope.security`` package as an ``install_requires`` dependency or
2) change the ZCML in their applications to use the declarations
from `repoze.zcml <http://static.repoze.org/zcmldocs/>`_ instead
of the stock declarations. ``repoze.zcml`` only makes available
the ``adapter``, ``subscriber`` and ``utility`` directives.
- The ``http://namespaces.repoze.org/bfg`` XML namespace is now the
default XML namespace in ZCML for paster-generated applications.
- The copies of BFG's ``meta.zcml`` and ``configure.zcml`` were
removed from the root of the ``repoze.bfg`` package. In 0.3.6, a
new package named ``repoze.bfg.includes`` was added, which
contains the "correct" copies of these ZCML files; the ones that
were removed were for backwards compatibility purposes.
Other
- The minimum requirement for ``chameleon.core`` is now 1.0b13. The
minimum requirement for ``chameleon.zpt`` is now 1.0b7. The
minimum requirement for ``chameleon.genshi`` is now 1.0b2.
|
|
|
|
scheme (see zope.component.adaptedBy); the change-log entry has detailed information.
|
|
|
|
- A ``repoze.bfg.location`` API module was added.
Backwards incompatibilities
- Applications must now use the ``repoze.bfg.interfaces.ILocation``
interface rather than ``zope.location.interfaces.ILocation`` to
represent that a model object is "location-aware". We've removed
a dependency on ``zope.location`` for cleanliness purposes: as
new versions of zope libraries are released which have improved
dependency information, getting rid of our dependence on
``zope.location`` will prevent a newly installed repoze.bfg
application from requiring the ``zope.security``, egg, which not
truly used at all in a "stock" repoze.bfg setup. These
dependencies are still required by the stack at this time; this
is purely a futureproofing move.
The security and model documentation for previous versions of
``repoze.bfg`` recommended using the
``zope.location.interfaces.ILocation`` interface to represent
that a model object is "location-aware". This documentation has
been changed to reflect that this interface should now be
imported from ``repoze.bfg.interfaces.ILocation`` instead.
|
|
|
|
special "uncacheable" discriminators (for actions that have
variable results).
|
|
exists).
|
|
- Remove dependency on FormEncode (only needed by sampleapp).
- Fix paster template generation so that case-sensitivity is
preserved for project vs. package name.
- Depend on ``z3c.pt`` version 1.0a1 (which requires the ``[lxml]``
extra currently).
|
|
``configure.zcml.pck`` next to the applications's "normal"
configuration file. A given bfg app will usually start faster
if it's able to read the pickle data. It fails gracefully
to reading the real ZCML file if it cannot read the pickle.
|
|
renamed to ``app`` in order to have a different name than the bfg
function of the same name, to prevent confusion.
- Add "options" processing to bfg's ``make_app`` to support runtime
options. A new API function named ``get_options`` was added to
the registry module. This function is typically used in an
application's ``app`` entry point. The Paste config file section
for the app can now supply the ``reload_templates`` option, which,
if true, will prevent the need to restart the appserver in order
for ``z3c.pt`` or XSLT template changes to be detected.
- Use only the module name in generated project's "test_suite" (run
all tests found in the package).
- Default port for generated apps changed from 5432 to 6543
(Postgres default port is 6543).
|
|
only one attribute: ``reload_templates``. If e.g.::
<bfg:settings reload_templates="true"/>
is in your application's ZCML, you will not need to restart the
appserver in order for ``z3c.pt`` or XSLT template changes to be
detected and displayed.
|
|
``bfg:view`` configure.zcml element. This attribute will have a
value which is a dotted Python path, pointing at an interface. If
the request object implements this interface when the view lookup
is performed, the appropriate view will be called.
- Remove "template only" views. These were just confusing and were
never documented.
|
|
calling a view, which is a callable that returns a response
directly (as opposed to returning a view). As a result, the
``factory`` attribute in the bfg:view ZCML statement has been
renamed to ``view``. Various interface names were changed also.
- ``render_template`` and ``render_transform`` no longer return a
Response object. Instead, these return strings. The old behavior
can be obtained by using ``render_template_to_response`` and
``render_transform_to_response``.
|
|
|
|
|
|
|
|
|
|
that the template be spelled on the class, while still allowing us to pickle the registry actions.
|
|
knowing their template's name.
|
|
|
