[Web-SIG] A trivial template API counter-proposal

[Alan Kennedy]

[Phillip J. Eby]
 > Developing WSGI was not easy, either, as I'm sure you recall.You and I
 > certainly argued a bit about iterators and file-like objects and such,
 > and it took a while before I understood all of your use cases and we
 > were able to resolve them in the spec.  If you had given up on
 > convincing me then, or if I had given up on your use cases as "too
 > complex", the spec would have suffered for it.

And I am indeed most grateful that you took the time to understand my 
tiresome ramblings on the subject: WSGI is indeed a most excellent spec: 
well done! :-)

[Alan Kennedy]
 >> I can understand why the web-sig has fallen into the trap of tying a
 >> tmeplating API to its nice web standard, WSGI: all web applications 
 >> must generate output. But web apps need to generate a wide range of
 >> media types, e.g. image/*, application/msword, etc, etc, etc.

[Phillip J. Eby]
 > And in many frameworks, it is the *template* that decides what media
 > type it is generating - and it may not even be outputting text or
 > unicode.  Again, this is something that would be neglected by a
 > text-only spec.

Ah, now there I have a problem! IMHO, templates should generate only a 
single media type. Whatever code is managing resource-delivery to the 
browser should decide which template to use, and set the media type 
accordingly, outside of the template.

Let me explain in terms of an actual use case.

I used to work for an e-learning company (widelearning.com), which 
delivered multimedia financial training materials. As much as possible, 
the content was delivered as video and Macromedia Flash, with fallback 
to simple image/* and text/html if the multimedia plugins were not 
available.

This was done through two primary mechanisms:

1. Through plugin detection, i.e. running script in the browser to 
detect certain plugins, e.g. Flash.

2. Through user profiles, i.e. where the user selected their media 
preference, which was stored in a database.

In both scenarios, entirely different templating engines were used.

For text/*html, we used XSLT and JSP (ugh ;-)

For Flash, we used a bespoke templating system, akin to Macromedia 
Generator (something like jgenerator: http://www.jzox.com). This was a 
templating engine that took a binary template as input, "cooked" the 
template with reference to a user data namespace, and generated a binary 
output stream representing a personalised Flash "movie".

Neither rendering engine had any knowledge that other media types could 
potentially be returned to the user. Before any templates were rendered, 
a decision was made as to what media type was suitable to service the 
request, maximising the capabilities of the users browser, and the 
relevant rendering engine invoked, with the relevant template. This 
"separation of concerns" greatly simplified our development and QA process.

IMO, permitting templates to select the media type is akin to the old 
problem of dealing with exceptions in various templating languages which 
intermingle code and presentation, e.g. JSP, ASP, PHP, etc. If a JSP 
caused an exception halfway through page-rendering, it was too late to 
do anything meaningful about it: the first half of the rendered page had 
already been transmitted to the user. What should really have happened 
is that the page should not have been transmitted to the user until the 
template was completely successfully rendered. That way, if an exception 
occurred, a suitable error page could be returned to the user, and the 
half-cooked template response discarded.

Similarly, if a template is permitted to set HTTP headers, then it might 
discover too late that it is generating a media type that is unsuitable 
for the client.

IMHO, some functionality in the HTTP application should decide the media 
type to be returned, call the relevant templating engine and set the 
relevant HTTP headers.

Looking at this in an MVC context, the application is responsible for 
populating the Model (user namespace), and selecting which View 
(template<->media-type) is suitable for return to the user. Templates 
should not vary media types. HTTP headers do need to be set for 
different templates/media-types. But that should be the responsibility 
of the HTTP application, not the template, which should be unaware of 
the application contect in which it is running, except for the contents 
of the Model/user-namespace.

Regards,

Alan.