Question

I have a web-app consisting of some html forms for maintaining some tables (SQlite, with CherryPy for web-server stuff). First I did it entirely ‘the Python way’, and generated html strings via. code, with common headers, footers, etc. defined as functions in a separate module.

I also like the idea of templates, so I tried Jinja2, which I find quite developer-friendly. In the beginning I thought templates were the way to go, but that was when pages were simple. Once .css and .js files were introduced (not necessarily in the same folder as the .html files), and an ever-increasing number of {{…}} variables and {%…%} commands were introduced, things started getting messy at design-time, even though they looked great at run-time. Things got even more difficult when I needed additional javascript in the or sections.

As far as I can see, the main advantages of using templates are:
Non-dynamic elements of page can easily be viewed in browser during design.
Except for {} placeholders, html is kept separate from python code.
If your company has a web-page designer, they can still design without knowing Python.

while some disadvantages are:
{{}} delimiters visible when viewed at design-time in browser
Associated .css and .js files have to be in same folder to see effects in browser at design-time.
Data, variables, lists, etc., must be prepared in advanced and either declared globally or passed as parameters to render() function.

So – when to use ‘hard-coded’ HTML, and when to use templates? I am not sure of the best way to go, so I would be interested to hear other developers’ views.

TIA, Alan

Answer 1

The simplest way to solve your static file problem is to use relative paths when referring to them in your html. For example: <img src="static/image.jpg" />

If you’re willing to put in a little more work, you can solve all the design-time problems you mentioned by writing a mini-server to display your templates.

1. Maintain a file full of simple data structures containing example values for all your templates.
2. Use a microframework like Werkzeug to serve http on your local machine.
3. Write a root request handler that scans your data structure list or templates directory to produce an index page with links to all your templates.
4. Write a secondary request handler for non-root requests, which renders the requested template with the data structure of the same name.

You can write this tool in a few hours, and it makes template design very convenient. One nice feature of Werkzeug’s built-in wsgi server is that it can automatically reload itself when it detects that a file has changed. You can leave your mini-server running while you edit templates and click links on your index page all day.