Hi Paul, I played with pyramid_layout recently and ran into the following problem: I have a library of layouts and panels which may be used in several apps so they get all registered in the includeme function of the library. But some apps may have to override a panel or a layout. But re-registering didn't work (ConfigurationConflictError) and there's no "remove_panel" method on the configurator. So how would i go about when I'd like to register a panel class (possibly derived from the panel in the library) instead of it's base class which has been registered before? regards robert
On Thu, Nov 8, 2012 at 1:15 PM, Paul Everitt <[email protected]> wrote: > > 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. > -- 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.
