| Age | Commit message (Collapse) | Author |
|
Ditch integration tests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tests didn't work.
|
|
|
|
- The view on the root shows a list of links to records.
- The view on a record shows the details for that object.
|
|
mismatch between test and view signatures.
|
|
Switch back to using a route with a subpath in the bfgalchemy paster template.
|
|
|
|
|
|
pipeline rather than "repoze.tm2", causing the startup to fail.
|
|
|
|
|
|
|
|
and actually uses the database during a view rendering.
|
|
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.
|
|
|
|
|
|
|
|
sets up a BFG project that uses SQAlchemy (with SQLite) and uses
Routes exclusively to resolve URLs (no traversal root factory is
used). This template can be used via ``paster create -t
bfg_routesalchemy``.
|
|
and cleanUp functions in repoze.bfg.testing. Our dependencies still rely on zope.testing, however.
|
|
|
|
So this updates the paster template tests so they pass again.
-----
r7827 | ianb | 2009-03-11 14:58:38 -0400 (Wed, 11 Mar 2009) | 1 line
Use Content-Type consistently (not content-type)
-----
|
|
contain images and CSS which are displayed when the default page is
displayed after initial project generation.
|
|
|
|
method accepts keyword arguments. Each key/value pair in the
keyword arguments causes an assertion to be made that the renderer
received this key with a value equal to the asserted value.
- Projects generated by the paster templates now use the
``DummyTemplateRenderer.assert_`` method in their view tests.
|
|
``transaction`` egg if we've got the one from ZODB 3.8.1).
Add a closer.
|
|
|
|
Added another template showing default ZODB setup using ``repoze.zodbconn``.
|
|
|