Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
100644 127 lines (97 sloc) 5.326 kb
69364d6 Tres Seaver Tidying
tseaver authored
1 :mod:`repoze.bfg` TODOs
2 =======================
4 - Supply ``X-Vhm-Host`` support.
6fd5e12 Review.
Chris McDonough authored
9ec2d64 Merge of andrew-docs branch.
Chris McDonough authored
6 - Basic WSGI documentation (pipeline / app / server).
ff1213e Add "exception views" work contributed primarily by Andrey Popp by mergi...
Chris McDonough authored
05d1f7d Get rid of some already-done items.
Chris McDonough authored
8 - Provide a webob.Response class facade for forward compat.
Chris McDonough authored
10 - Fix message catalog extraction / compilation documentation.
84c5ec6 lingering todo items
Chris McDonough authored
12 - Change docs about creating a venusian decorator to not use ZCA.
14 - Add a ``susbcriber`` decorator and docs.
16 - Venusian: skip .pyc-only files.
30e64f3 Make default_notfound_view and default_forbidden_view expect an exceptio...
Chris McDonough authored
388f9d4 renderer overhaul intentions
Chris McDonough authored
18 Renderer overhaul
19 ------------------
21 Currently the division of responsibility between the BFG configurator
22 and a BFG renderer implementation is awkward and wrong.
24 - Renderer factories have no ability to convert a raw ``renderer=``
25 path (e.g. ``templates/```) into something internally
26 meaningful. Instead, BFG mangles the string into a package-relative
27 spec before it is passed to the renderer factory. This is wrong, as
28 some renderers may not be interested in package-relative specs at
29 all (for instance, loader-style renderers which have a hardcoded set
30 of template locations). The reason, however, that BFG currently
31 does it this way is that the raw renderer path alone does not
32 contain enough information itself to be useful; knowledge of the
33 *package* is also required for package-based renderers to make sense
34 of relative renderer strings (e.g. ``templates/`` could mean
35 the ``templates/`` file within the ``mypackage`` package).
37 To fix this, we need to provide some way to pass the package name to
38 the renderer factory as well as the renderer path. But the package
39 name isn't the only thing an *arbitrary* renderer might need.
40 Another renderer might need, for example, a deployment setting. So
41 we'll need to identify all the crap that *might* be useful to a
42 renderer factory and we'll need to pass all of it into the renderer
43 factory as a garbage barge dictionary; individual renderers will
44 make use of whatever they can from that garbage barge dictionary.
45 Garbage barge dict item candidates: ``package`` (the "current"
46 package), ``config`` (the configurator), ``package_name`` (the
47 current package's ``__name__``), ``settings`` (the deployment
48 settings), ``registry`` (the component registry).
50 - A BFG renderer currently returns a *string*. It would be more
51 symmetric if a renderer always returned a Response object. Then the
52 calling machinery inside BFG could treat a view which happened to
53 use a renderer exactly the same as a view which returns a response
54 directly. Maybe. Problem: varying response attributes such as
55 ``content-type``, etc only makes sense when the view callable uses a
56 renderer; not when it doesn't, so there's some asymmetry there.
57 Maybe we make renderers return Responses, but still keep the
58 attribute-inspection stuff inside BFG, only used when we call a view
59 which we know uses a renderer. We *could* always call the attribute
60 inspection stuff, but it would be a slowdown in cases where views
61 really do always return a Response directly.
63 - The ``system`` value passed to a renderer is not extensible. It
64 should be extensible on a per-application basis. For example, you
65 might want to add a top-level variable ``c`` to the values passed to
66 all renderers representing a template context to emulate Pylons.
68 - ``repoze.bfg.chameleon_zpt.render_template_to_response``, et. al. do
69 not use the same machinery as view renderers. It would be useful if
70 templates rendered with ``render_template_to_response`` had the same
71 ``system`` values available to it as templates renderered via a view
72 renderer.
74 To at least partially ameliorate the above, renderer factories should
75 be changed to things that have a set of interfaces something like
76 this::
78 class IRendererFactory(Interface):
79 def __call__(path, info):
80 "" Return an IRenderer."""
82 class IRenderer(Interface):
83 def __call__(value, system):
84 """ Return a Response """
86 A semi-pseudocode example:
88 from webob import Response
90 class SampleRendererFactory(object):
91 def __init__(self, **config):
92 self.config = config
94 def __call__(self, path, info):
95 path = do_something_to_evaluate_path_using_info(path, info)
96 search_path = self.config['search_path']
97 debug = self.config['debug']
98 def renderer(value, system):
99 string = do_rendering(search_path, debug, path, value, system)
100 return Response(string)
101 return renderer
103 if __name__ == '__main__':
105 def view1(request):
106 return {'a':1}
108 def view2(request):
109 return {'a':2}
111 renderer_factory = SampleRendererFactory(search_path=['/a', '/b'])
113 package_name = 'some.package'
115 for view, path in [
116 (view1, 'templates/'),
117 (view2, 'templates/'),
118 ]:
119 renderer = renderer_factory(path, dict(package_name=package_name))
120 register_renderer_for_view(renderer, view)
122 This is mostly an amelioration for the first and second bullet points
123 above. The second two bullet points are not addressed by it.
84c5ec6 lingering todo items
Chris McDonough authored
125 Also: think about generalizing this a bit into something which wraps a
126 view callable like a decorator, which can influence input and output.
Something went wrong with that request. Please try again.