1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
|
Next release
Features
- 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.
0.3.8 (08/26/2008)
Docs
- Documented URL dispatch better in narrative form.
Bug fixes
- Routes URL dispatch did not have access to the WSGI environment,
so conditions such as method=GET did not work.
Features
- Add ``principals_allowed_by_permission`` API to security module.
- Replace ``z3c.pt`` support with support for ``chameleon.zpt``.
Chameleon is the new name for the package that used to be named
``z3c.pt``. NOTE: If you update a ``repoze.bfg`` SVN checkout
that you're using for development, you will need to run "setup.py
install" or "setup.py develop" again in order to obtain the
proper Chameleon packages. ``z3c.pt`` is no longer supported by
``repoze.bfg``. All API functions that used to render ``z3c.pt``
templates will work fine with the new packages, and your
templates should render almost identically.
- Add a ``repoze.bfg.chameleon_zpt`` module. This module provides
Chameleon ZPT support.
- Add a ``repoze.bfg.xslt`` module. This module provides XSLT
support.
- Add a ``repoze.bfg.chameleon_genshi`` module. This provides
direct Genshi support, which did not exist previously.
Deprecations
- Importing API functions directly from ``repoze.bfg.template`` is
now deprecated. The ``get_template``, ``render_template``,
``render_template_to_response`` functions should now be imported
from ``repoze.chameleon_zpt``. The ``render_transform``, and
``render_transform_to_response`` functions should now be imported
from ``repoze.bfg.xslt``. The ``repoze.bfg.template`` module
will remain around "forever" to support backwards compatibility.
0.3.7 (09/09/2008)
Features
- Add compatibility with z3c.pt 1.0a7+ (z3c.pt became a namespace package).
Bug fixes
- ``repoze.bfg.traversal.find_model`` function did not function
properly.
0.3.6 (09/04/2008)
Features
- Add startup process docs.
- Allow configuration cache to be bypassed by actions which include
special "uncacheable" discriminators (for actions that have
variable results).
Bug Fixes
- Move core repoze.bfg ZCML into a ``repoze.bfg.includes`` package
so we can use repoze.bfg better as a namespace package. Adjust
the code generator to use it. We've left around the
``configure.zcml`` in the repoze.bfg package directly so as not to
break older apps.
- When a zcml application registry cache was unpickled, and it
contained a reference to an object that no longer existed (such as
a view), bfg would not start properly.
0.3.5 (09/01/2008)
Features
- Event notification is issued after application is created and
configured (``IWSGIApplicationCreatedEvent``).
- New API module: ``repoze.bfg.view``. This module contains the
functions named ``render_view_to_response``,
``render_view_to_iterable``, ``render_view`` and ``is_response``,
which are documented in the API docs. These features aid
programmatic (non-server-driven) view execution.
0.3.4 (08/28/2008)
Backwards incompatibilities
- Make ``repoze.bfg`` a namespace package so we can allow folks to
create subpackages (e.g. ``repoze.bfg.otherthing``) within
separate eggs. This is a backwards incompatible change which
makes it impossible to import "make_app" and "get_options" from
the ``repoze.bfg`` module directly. This change will break all
existing apps generated by the paster code generator. Instead,
you need to import these functions as
``repoze.bfg.router:make_app`` and
``repoze.bfg.registry:get_options``, respectively. Sorry folks,
it has to be done now or never, and definitely better now.
Features
- Add ``model_path`` API function to traversal module.
Bugfixes
- Normalize path returned by repoze.bfg.caller_path.
0.3.3 (8/23/2008)
- Fix generated test.py module to use project name rather than package
name.
0.3.2 (8/23/2008)
- Remove ``sampleapp`` sample application from bfg package itself.
- 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).
- Read and write a pickled ZCML actions list, stored as
``configure.zcml.cache`` 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.
0.3.1 (8/20/2008)
- Generated application differences: ``make_app`` entry point
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).
0.3.0
- Add ``get_template`` API to template module.
0.2.9
- 0.2.8 was "brown bag" release. It didn't work at all. Symptom:
ComponentLookupError when trying to render a page.
0.2.8
- Add ``find_model`` and ``find_root`` traversal APIs. In the
process, make ITraverser a uni-adapter (on context) rather than a
multiadapter (on context and request).
0.2.7
- Add a ``request_type`` attribute to the available attributes of a
``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. This is meant
to allow for simple "skinning" of sites based on request type. An
event subscriber should attach the interface to the request on
ingress to support skins.
- Remove "template only" views. These were just confusing and were
never documented.
- Small url dispatch overhaul: the ``connect`` method of the
``urldispatch.RoutesMapper`` object now accepts a keyword
parameter named ``context_factory``. If this parameter is
supplied, it must be a callable which returns an instance. This
instance is used as the context for the request when a route is
matched.
- The registration of a RoutesModelTraverser no longer needs to be
performed by the application; it's in the bfg ZCML now.
0.2.6
- Add event sends for INewRequest and INewResponse. See the
events.rst chapter in the documentation's ``api`` directory.
0.2.5
- Add ``model_url`` API.
0.2.4
- Added url-based dispatch.
0.2.3
- Add API functions for authenticated_userid and effective_principals.
0.2.2
- Add authenticated_userid and effective_principals API to security
policy.
0.2.1
- Add find_interface API.
0.2
- Add wsgiapp decorator.
- The concept of "view factories" was removed in favor of always
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``.
- Added 'repoze.bfg.push:pushpage' decorator, which creates BFG views
from callables which take (context, request) and return a mapping of
top-level names.
- Added ACL-based security.
- Support for XSLT templates via a render_transform method
0.1
- Initial release.
|
