At 12:29 PM 2/1/2006 -0600, Ian Bicking wrote: >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.
Actually, I believe you've got that backwards. Many things the WSGI embedding proposal can do, yours can't do *at all*, no matter how much programming you do. vars'n'strings isn't a substitute for WSGI, but it's easy to piggyback other payloads *out* of WSGI using file_wrapper-like APIs or dual-use objects with "__call__" methods. > 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 one thing, you can use extension APIs, like wsgi.file_wrapper. For another, note that requiring a compiled template to be a WSGI app doesn't require a calling or extending template to restrict itself to interacting via WSGI. If you have some kind of "find_template" extension API that's called, the template is free to sniff the returned resource for something "better" than WSGI for its purposes, like a Cheetah base template or a peak.web IDOMlet, or a PSO tag, or any of a dozen other specialized templating technologies. They just have to *also* be WSGI apps if there's any chance they might be used to respond to a page request. (Example: peak.web IDOMlets have separate methods to behave as a WSGI-like response handler and as a fragment generator for insertion into another DOMlet's page, which also allows them to be smart about including surrounding content; thus they can dynamically "inherit" (to use the common slang for applying a layout) depending on whether they are being used as a fragment or a full page, and optionally applying content negotiation as well. This is another example of a kind of feature where the vars'n'strings proposal seems to fall short of enabling.) >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. Provide extension APIs to allow finding other templates. Putting them in this context also helps make it clear that such APIs aren't -- and *can't* be -- universal, because the templates themselves aren't heterogeneous. You can't give a Cheetah template a Kid subtemplate. I'd prefer to take up template finding in the context of a resource deployment proposal, where I think we can get a lot more leverage. But if it enables needed use cases today, I could get behind providing a simple -- and *optional* -- template finding API as part of the WSGI template/resource proposal, especially if discussing it helps lay the groundwork for the resource deployment proposal. >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. You're presuming a controller-based architecture here, not an object-publishing one or a PHP/ASP style "active pages" one. That's ignoring what, maybe half the web frameworks? _______________________________________________ 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
