durusmail: quixote-users: Header and footer PTL Plug-in?
Header and footer PTL Plug-in?
2005-11-07
2005-11-15
Header and footer PTL Plug-in?
mario ruggier
2005-11-15
On Nov 7, 2005, at 9:30 AM, Shalabh Chaturvedi wrote:

> I'm trying to write Quixote applications that can be re-used easily.
> So I do not want to bind the PTL templates tightly with my site
> header, footer and other standard 'pieces' of a page. My current
> strategy is to use:
>
> import pageui
>
> def someview [html] ():
>     pageui.header()
>
>     ...
>
>     pageui.footer()
>
> And not include pageui.ptl in this package at all. The user of this
> app then has to create pageui.ptl and make sure it is in the
> pythonpath. This allows me (and others) to re-use the application with
> different headers, footers and such.
>
> 1. Is this a good approach?

I have been doing something very similar also, as I expect that anyone
who has had to manage the building of non-trivial pages has also. I
have been meaning to reply to this earlier, but my code is not ready
for just posting, so I took a little time now to review what I had
done, and write it up somewhat clearly.

One problem I see with what you propose is that what happens if an
error occurs in teh middle of your view rendering? And, the page you
wish to display uses a different visual style in that case.

I have a whole scheme, that tries to do a lot more than what you are
after I think,  by which a page_info object is constructed during page
processing, and then rendering will cause that all (css, js) x (files,
code snippets) will be conveniently placed in the head element,
irrespective of where they have "sprung out" from within the page,
making page easier to load, and debug...

> 2. Is there value in standardizing the 'pageui' API? For example I end
> up using not just header() and footer() but also msg_box(msg),
> link_button(label, target) and other such components.

I have also included info of how I handle rather complex page
components, that have their own behaviour and interaction. These also
know how to talk to the page_info object.

My current implementation, for quixote, is not as clean as the partial
description in the attached file. As I will probably be revising it
anyway, and possibly doing it for qp, I would appreciate any comments
you may have, even suggestions of better names. I also would be happy
to converge this with other similar efforts that may be going on... QP
already has a very simple idiom for rendering a page, namely that
publisher.page() renders by calling publisher.header() and
publisher.footer(), that are therefore easily overridden by the site's
publisher. What I describe is actually not very different, but more
general i think. I'd also be interested of ideas of how best to add
this onto qp... but ill take that to that list.

mario



reply