Hi Robert. I was just working with something that did this yesterday, so perhaps there is a pyramid_layout bug I didn't run across.
Can you make a test case and send it to me? --Paul On Nov 8, 2012, at 7:22 AM, Robert Forkel <[email protected]> wrote: > 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. > -- 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.
