| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2010-10-25 | first pass at converting bfg to pyramid namespace | Chris McDonough | |
| 2009-10-18 | - More than one ``@bfg_view`` decorator may now be stacked on top of | Chris McDonough | |
| any number of others. Each invocation of the decorator registers a single view. For instance, the following combination of decorators and a function will register two views:: from repoze.bfg.view import bfg_view @bfg_view(name='edit') @bfg_view(name='change') def edit(context, request): pass This makes it possible to associate more than one view configuration for a single callable without requiring ZCML. | |||
| 2009-09-20 | Make instance grokking work again. | Chris McDonough | |
| 2009-09-20 | - The way ``bfg_view`` declarations are scanned for has been modified. | Chris McDonough | |
| This should have no external effects. - An object implementing the ``IRenderer`` interface (and ``ITemplateRenderer`, which is a subclass of ``IRenderer``) must now accept an extra ``system`` argument in its ``__call__`` method implementation. Values computed by the system (as opposed to by the view) are passed by the system in the ``system`` parameter, which will always be a dictionary. Keys in the dictionary include: ``view`` (the view object that returned the value), ``renderer_name`` (the template name or simple name of the renderer), ``context`` (the context object passed to the view), and ``request`` (the request object passed to the view). Previously only ITemplateRenderers received system arguments as elements inside the main ``value`` dictionary. | |||
