Phillip J. Eby wrote: >> 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.
What exactly can't I do with a WSGI application (a specific implementation) that uses the non-WSGI plugin API? >> 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. My API always indicates the type of object you are looking for, though that may be too strict, as you don't *always* want to have a single type. Though if there is a defined exception when a resource can't be found, maybe that could be handled at a higher level than find_resource. > 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? object-publishing is a subset of controller-based frameworks, where there is a single controller known as the "object publisher". In an active page model the controller is the framework (insofar as you want to project MVC terminology onto such systems). Here's a rough WSGI implementation of active pages using the resource spec: class TemplateApp(object): def __init__(self, find_resource, ext_to_plugin, index_name, default_ext): self.find_resource = find_resource # a dictionary of extensions to instantiated plugins: self.ext_to_plugin = ext_to_plugin self.index_name = index_name self.default_ext = default_ext def __call__(self, environ, start_response): # actually empty path_info should cause a redirect... path_info = environ.get('PATH_INFO', '/') if path_info.endswith('/'): path_info += self.index_name parts = path_info.rsplit('.', 1) if len(parts) == 1: ext = self.default_ext resource_name = path_info + ext else: ext = '.'+parts[1] resource_name = path_info plugin = self.ext_to_plugin[ext] environ['response.headers'] = {'Content-type': 'text/html'} resource = self.find_resource(plugin, resource_name) body = response.plugin.render(resource, {'environ': environ}) start_response('200 OK', environ['response.headers'].items()) return [body] There's a bunch of sloppy WSGI constructs, and the environment isn't a great request object, but that's not really the point. -- 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