On Nov 8, 2012, at 2:46 AM, Andreas Kaiser <[email protected]> wrote:
> > On 07.11.2012, at 22:21, Marten <[email protected]> wrote: > >> I searched a lot through documentation and examples, but I couldn't find any >> best practise on how to tie together a bunch of views to one page. >> >> You'll surely know dashbords that contain dozends of containers like load >> graphs, contact details, latest tasks in history, pending transactions of >> whatever ... Each container on its own is a usual view that renders fine on >> its own, but there has to be some master page, that includes all these >> views. And it would be crazy to prepare all data in one view and feed a >> mega-template. >> >> As similar problem arised during my development, when handling non-static >> headers like menu tree and user profile ("Hello <name>!" or "Login"). I know >> how to define a template so it loads a surrounding master template, but I >> don't know how to tell feed that with data. I also know how to bind a >> subscriber to a new request, but that would be processed before the view is >> called. And especially regarding a login view it depends on whether the >> login attempt was successful or not which "Hello <name>!" or "Login" has to >> be rendered in the surrounding template. I think the views itself shouldn't >> know anything about menus and user details. Access permissions can be >> defined by roles on views. >> >> What is the best practise to do such things? Can you refer to any public >> source code on git (was well as a working website running this code so I see >> if it does what I mean) or examples in documentation? Thanks. > > pyramid_layout might be what you are looking for: > > - http://pypi.python.org/pypi/pyramid_layout > - http://pyramid_layout.readthedocs.org/en/latest/index.html As one of the people involved in pyramid_layout, I unbiasedly agree. :) pyramid_layout has two ideas: layouts and panels. Panels are re-usable, callable snippets of templating and code. Since it is an extension of the view machinery, it inherits a lot of Pyramid coolness (overriding, for example.) For example, a sales graph: @panel_config(name="sales_graph", renderer="path to template") def sales_graph(request, context, axes, values): do some stuff and make some data return dict(data=data) Then, call it from one of your templates. For example, calling from ZPT: ${panel('sales_graph', axes=these_axes, values=these_values)} Most templating systems have reuse of templating (macros, etc.) pyramid_layout panels take that three steps further: - Templating *and* the logic for that template, as a unit - Callable, with parameters - Overridable with normal Pyramid machinery Again, since this uses the pyramid view machinery, it isn't a lot of code and isn't too heavy conceptually. --Paul -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
