How to handle multiple views in one page

[Marten]

Hello,

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.

Kind regards

Marten

[Andreas Kaiser]

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


HTH,

Andreas

[Arndt Droullier]

Pyramid provides several options to call views or templates from inside your application code.

They make quite easy to reuse templates and views.

See "pyramid.renderers" for template rendering or "pyramid.view" for views.

e.g. 

    from pyramid.view import render_view

    ...

    return render_view(context, request, view_name, secure)

invokes the view including template lookup, security and so on. 

Or 

    from pyramid.renderers import render

    ...

    html = render("one_template.pt", {}, request=request)

gives you control over the template to be rendered.

Arndt.

2012/11/7 Marten <leh...@cnm.de>

Marten

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/0quNBRga8dMJ.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.

--
DV Electric / Arndt Droullier / Nive cms cms.nive.co

[Paul Everitt]

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

[Robert Forkel]

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

> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

[Jonathan Vanasco]

in my opinion there is no best-practice to handle this.  it all depends on how you want to structure the application for ease-of-development vs where you're willing or unwilling to take performance hits.

[Marten]

Performance doesn't have priority. It's a typical web application with some database queries, some forms with input validation, but no heavy calculations, so even outdated servers could handle hundrets of concurrened requests.

My focus is rather on reusing code. Lets say I have an "applet" to edit contact details. There will be a read-only view and a form to edit with some input validation. This sub-application shall be reused in different contexts.

For example an administrator would use it through the URL /customer/1234/edit and the container might be part as a tab of a surrounding container where other tabs contain lists of his invoices, login history and such.

The enduser would access it through /my-details/edit, being part of a dashboard along with fancy graphs, buttons to order new products and whatever.

Doing that from scratch would mean, that all of the inhouse routing and view functionality of pyramid would be pretty useless and I would degrade it to a database pool with ORM and manually call renderers. I can't imagine that I'm the first to master this challenge.

[Jonathan Vanasco]

in my experience, what you describe ultimately has a lot of performance issues due to database bottlenecks and complicated caching .

i could be wrong , but i think you're overthinking this. why try to integrate multiple "views".  why not deconstruct your views into partials and a code library.

you can do a lot of "partials" with templates.  if you're using mako, just create a partials directory and either include them or use them as functions in a namespace.  you should make them as  dumb as possible - have them just operate on python dicts / json objects, or offload some work into them (mako lets you run raw python in the templates )   you could try to aggressively preload data for the templates in the views --  it would be easier to deal with caching and stuff here.

with an approach like this, your views would dictate something like:

class view_factory(object):

    def my_view(self):

        self.request.template_data = {

            'contact_form' : { dict }

        }

templates/admin/customer/edit.mako

    - include templates/partials/profile.mako

    - profile( request.tempalte_data['contact_form'])

templates/customer/profile/edit.mako

    - include templates/partials/profile.mako

    - profile( request.tempalte_data['contact_form'])

templates/partials

    - profile.mako

    def profile( dict ):

         form logic

you could also consider an approach where everything is javascript driven.  you could render some initial data within pyramid, and have something like backbone.js or moustache do the on-screen renderings + api communication.

[Paul Everitt]

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