| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
