Kevin Dangoor wrote: >>>Thoughts? >>> >>>Peter Hunt >>> >>>[1] http://www.turbogears.org/docs/plugins/template.html >> >>I concur. I've started using it in a project of mine. There's a couple >>things I'd like to add that have come up on the TG list: >> >>* Add "template_file" and "template_string" arguments to .render(), >>which take filenames and strings. > > > Would template_file be expecting an absolute filename? (just > confirming that this wouldn't do any more lookups or path searching... > just open and go!)
I'm thinking if it is an absolute filename, it should be treated as an exact reference. If not, then you search for the file in the search path. Though maybe that logic should be in find_template. For instance, sometimes you might want to force the template to be under some base directory (e.g., for security reasons), so find_template might treat absolute filenames as relative to that directory. I think some default/recommended implementation of find_template would also be useful, at least to see how common features are implemented in terms of it. >>* Add a find_template callback, which given a filename can, for >>instance, use a search path to find the file. So the framework or >>application would pass this function into the plugin somehow. Maybe >>this could be extended some for use in situations where templates aren't >>found on the filesystem. > > > Being able to pass a string to render() would also allow use where the > templates aren't in the filesystem. Yes; I was thinking of implementing Subway's use of docstrings for templates, and realized I couldn't do it with the interface as it is. > In fact, if find_template is just returning a filename, then this > mechanism couldn't work for pulling the template from a database. It could work partially. I was figuring that if you did something like include another template or inherit or whatnot (every language has its own name for this) then that template would have to be in the filesystem, or more generally somewhere that find_template can find it. Maybe it would be better if find_template actually ultimately called load_template, and load_template became a bit more useful. So instead of render being called with the template name, it is called with whatever load_template returns. This would also allow languages like PyMeld to participate partially, in that users could use load_template to get the templates, even if they could not use render. >>* Add some methods for quoting -- one for text that is already a >>HTML/XML literal, and one for text that should be quoted. Some >>templates default one way (quote everything unless explicitly asked not >>to in some way), and some the other way (include everything as though it >>is markup, unless explicitly quoting it). This makes it possible -- >>though not incredibly easy -- to write some template-language-neutral >>libraries. I would assume most applications would actually be written >>to a specific templating language, so this is only for libraries that go >>out of their way to be neutral. > > > That sounds potentially hairy. Not the specifics of having the quoting > methods, but rather the notion of having template-language-neutral > libraries that use these. Are you thinking of something specific? that > might make it clearer to me. I'm not sure at this point. You'd actually have to tell the library what template language you were planning to use with it; I don't think any single quoting will work, because the quoting might happen deep in some nested structure. But the idea is that a library like a widget-generation library could work better across languages. -- 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