Phillip J. Eby wrote: >>This topic started with Buffet, the de-facto standard templating API for >>CherryPy. Buffet is just about textual templating, which is a good >>thing. That's why it's very simple, and is thus actually being used. > > > Which is precisely why we don't need to rush into blessing it as some kind > of web standard, when it doesn't have anything to do with the "web", as far > as I can tell. If I needed a plugin for pure text or XML templating (as > opposed to *web application* templates), or I were creating a pure text or > XML output generator, I would absolutely use the TG/Buffet API, no > question. It is 100% the right tool for the job, and the de facto standard > as well. > > But I'm also 100% positive that it is *not* suitable to be declared a > Python *web* standard by itself: it's not about the web at all. The web > just happens to be where it's being used at the moment, and only in > frameworks where the use cases slot neatly together with it. Heck, just > look at the API documentation and see if you can find the word "web" or > even "request" mentioned on the page: > > http://www.turbogears.org/docs/plugins/template.html
It is not a complete spec that fits many use cases at this time. It won't be sufficient for TG either before long -- Kevin has already said that he'd like a find_template function somewhere in there. Because the spec suggests that templates are given module-like names coinciding with the package of the consuming software, it is hard to use in any way where the templates themselves are taken from arbitrary locations. It doesn't actually specify how the names are interpreted or how the templates are found, but all the implementations so far use pkg_resources and load templates in a way that makes it difficult to load arbitrary files. This probably seemed sensible since the first couple languages -- Kid and Cheetah -- compile to Python modules. But while it seems sensible, Python modules are far more difficult to work with than simpler metaphors for a compiled template -- you get import hooks, rather complicated recompilation steps, and add one more thing to the already complex task of managing sys.path. So no, this isn't sufficient now. I think very minor fixes could improve it -- for instance, allow template_filename as an argument instead of only template_name. Then at least simple template filling would be handled well (e.g., enough for Paste Script), though it is unlikely (with only those specs) that templates will handle including other templates very well, as there's not even sufficient information given for the template language to figure out the programmer's intent. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
