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

[Guido van Rossum]

On 2/5/06, Ian Bicking <ianb at colorstudy.com> wrote:
> * There was an ad hoc standardization happening with TG and Buffet.
>
> * Other people were becoming interested.
>
> * Discussion was happening on the TG list, where most people on the TG
> list were not particularly interested about this sort of thing.
>
> * There are still several outstanding issues with the spec.
>
> * People came upon this ad hoc standard rather randomly through word of
> mouth, and Peter Hunt thought that maybe the spec should be promoted more.
>
> * Almost everyone doing stuff on the web cares about templates.
>
> * Web applications and frameworks are the primary consumers of
> templating languages, and the vast majority of templating languages were
> written with web use in mind.  Except maybe string.Template, I can't
> think of ANY templating language not written with the web in mind.
>
> * Most templating languages are interfaced in very similar ways -- dict
> of variables in, string out.  Despite the fact that these languages were
> written for the web, people still haven't felt a need to go beyond this.
>
> * But the exact details of invoking the template vary widely, in ways
> that are very annoying for people who want to support multiple
> languages.  It is even very annoying for people who only want to support
> one language, because the interfaces often have several options and
> there's never been a particular target API for template language authors
> to shoot for.  There's no "best practice" for this side of the API design.

Thanks for confirming that I'm not entirely out of my mind.

There's too much written here for me to respond on directly, but I
like the way things are going -- genuine consideration of the
complexity of the issues, and the desire to have an inclusive
standard.

I seem to accidentally have caused some confusion by writing "how can
it be considered a templating system if it has no access to
request/response?" -- Reading back I can't quite reconstruct what I
*meant* to say, but it was more like the opposite -- e.g. "how can you
exclude templating systems that don't need access to
request/response?" My apologies.

Phillip described the workflow for Django/Cheetah style templates as follows:

> * framework calls some Python code you wrote
> * your code returns a dictionary of values you want rendered
> * framework passes your returned values to the template, gets back a string
> * framework sends the string back to the browser

But there's an even lower-level variant, where the Python code
referenced invokes the template (with variables) and receives a string
back, which it possibly munges further and then passes to the
framework. (For example, my first attempt at using Django templates
had one piece of Python code that concatenated the results from
several templates.)

I'd like someone to write up a similar list explaining how e.g. Zope3
differs -- I suppose at one point in the past I used to know, but that
knowledge is on a back-up tape that was lost after I moved to
California. :-(

Phillip also wrote this:

> As Ben has previously pointed out, systems like Myghty are going to ignore
> your 'find_template()' because they do their own finding.  So the spec will
> leak no matter what, until we get to the level of specification called for
> by the "embedding" side of my proposal.  (The compile/write stuff.)  And
> Ben and Michael have both pointed out that trying to meet a spec that calls
> for them to change how their inner find_template works would be costly.

I can't parse this because I don't know what relationship Ben and
Michael have with the systems mentioned.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)