On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> 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/) _______________________________________________ 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