Phillip J. Eby wrote: > At 08:11 PM 1/31/2006 -0600, Ian Bicking wrote: > >> Please, say what is wrong about the spec itself, not what is wrong >> about the scope of the spec. > > > The first things that come to mind are: > > 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. > 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? The actual templates written are implicitly bound to the application and the framework, and the application is bound to the template language, and maybe we can solve that problem later. This just handles the template/framework binding. > 3. Doesn't allow the framework to control the lifetime of compiled > resources Ok... so what should we do? We can say that .load_template is not allowed to cache the thing it returns, and require find_resource to do the caching. > 4. Lack of relationship to HTTP makes it irrelevant/out-of-scope for > Web-SIG; it should go to a string or text processing SIG. There isn't such a sig. And it's all just mailing lists anyway. The people who care about this now are doing web work. > 5. Makes Web-SIG do-over a problem that TurboGears and Buffet have > already solved. (That is, there's already a usable solution for what > this does; it doesn't need *another* specification; let's use the > current focus of attention to go after an actual opportunity to *improve*.) We have discussed some improvements on the TG list, and I've tried to bring those up here as well. And the interface is like a couple weeks old, so it's not like this particular solution is As Old As The Hills and shouldn't be considered by a wider audience before moving forward. > Problems 1-4 are simple to solve by having resources be WSGI application > objects. The rest of the standardization could then be reduced to what > additional environ keys should be supplied by frameworks. And then we > could get to work on solving the resource deployment problem instead. > > Look-and-feel customizability of reusable web application components is > an incredibly important problem, on a scale comparable to the problems > that setuptools and eggs solve, and it's a much bigger issue for > man-in-the-street use of Python as a web platform than WSGI itself is. > My wife isn't a programmer, but she's hacked PHP applications to > customize their look and feel. (Of course, these apps then aren't > really upgradeable any more, because their code has effectively been > branched.) These are all important issues -- I entirely agree. When I wrote a list of features I'd want in an ideal web development environment (http://blog.ianbicking.org/ideal-webdev-environment.html), these kind of features take up a sizable portion of the list. But I don't see how this spec -- or particularly the spec I proposed in response to you (http://mail.python.org/pipermail/web-sig/2006-February/001926.html) -- disallows these kinds of features being developed in the future. In fact quite the contrary! By giving that resource finding process a name and purpose -- even if not an implementation -- I think this spec strongly encourages such development (or extraction) in the future. I just can't see why one needs to be a prerequesite for the other. But people want the template plugin *now*, and working on what people want is generally a good strategy. -- 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
