Phillip J. Eby wrote: >>It is my strong preference that the standard API we are attempting to >>design here does *not* tie you strongly to WSGI or the generation of >>dynamic web content. > > > That seems to be a popular position, to be sure. However, since there is > already a de facto standard support for that simpler use case, that is > already supported by two frameworks for at least 6 templating systems(!) it > seems that it's already both a solved problem and outside the scope of the > Web-SIG. You already *have* this standard API; why shouldn't the web-sig > then focus on something that supports *web* templating, not just strings?
Here is exactly why: * 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. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
