Clark C. Evans wrote: > On Tue, Jan 31, 2006 at 09:04:43PM -0600, Ian Bicking wrote: > | Phillip J. Eby wrote: > | >1. It disadvantages better solutions (whether frameworks or templates) > | >by reducing everything to the least common denominator > | > | I think exposing load_template is an escape for template languages that > | don't fit into the standard dictionary-in-string-out approach. Besides > | that, I don't know what Better Solution we're talking about. > > I don't see how something like this disadvantages better solutions. If > anything, I can see how it would enable quicker adoption of better > solutions: an adapter from this "simple" interface to the "better" > interface would be easy to construct and thus give out of the gate > any better interface a leg-up.
My criteria is that it would be easy to implement Phillip's proposal in terms of mine (and I could provide a sample implementation of that if it would help), but it doesn't seem so easy to do the opposite. Maybe not possible, because templates often need to get to raw (not plugin or WSGI wrapped) version of subtemplates (using communication APIs that are not standard and are not part of any of these specs). For instance, there's no way for a Cheetah template to extend a WSGI application. It can extend other Cheetah templates, and even other Python classes, but not a WSGI app. > | >2. It doesn't give templates access to the request or response without > | >creating new specifications for how they're to be encoded in vars -- > | >which would end up recapitulating the pre-WSGI "common > | >request/response" arguments all over again > | > | The spec doesn't say anything about the variables passed in. I guess > | there's an implication that it is a dictionary, though that might not be > | necessary. The request and response are variables. Why would they be > | something other than variables? Even in Zope they are variables, right? > > Ian, my "templates" use the Accept header to figure out what sort of > content variant to return; plus a quick peek at the User-Agent for > last-minute compatibility tweaks. How does the current/proposed > templating system support this? These things arn't exactly "inputs" > that get renderd into the output string. It's up to you to handle that in your application. So you might pass in the WSGI environment as some variable, or the specific header, or you might select a template based on that header. For instance, you might have a convention that templates are named like foo.text.plain.tmpl for a template that produces text/plain output. Then you make a find_resource implementation that is bound to the current request, and looks at the accept header to select the appropriate template from the intersection of Accept and the available templates. Or, you could simply pass in the environment to the template and assume that the template will produce the correct template. For instance, maybe you make your own template plugin that wraps other template plugins, and does automatic conversion from text/html to text/plain if necessary. There isn't any very good way to send metadata about the result of the template rendering, and I can see there being some utility to allowing that. For instance, indicating what mime type was actually generated, instead of trusting that the mime type given was used. Or indicating what encoding the output is in (if you don't return unicode). While these aren't strictly necessary -- you can just trust your template to do what you tell it to do -- it would be nice. -- 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
