On Feb 5, 2006, at 11:32 PM, Guido van Rossum wrote: > Phillip described the workflow for Django/Cheetah style templates > as follows: > >> * framework calls some Python code you wrote >> * your code returns a dictionary of values you want rendered >> * framework passes your returned values to the template, gets back >> a string >> * framework sends the string back to the browser > > But there's an even lower-level variant, where the Python code > referenced invokes the template (with variables) and receives a string > back, which it possibly munges further and then passes to the > framework. (For example, my first attempt at using Django templates > had one piece of Python code that concatenated the results from > several templates.) > > I'd like someone to write up a similar list explaining how e.g. Zope3 > differs -- I suppose at one point in the past I used to know, but that > knowledge is on a back-up tape that was lost after I moved to > California. :-(
Zope 3 usually works like this: - framework calls your view code, usually with a context object and a request (which has a response). - your code can set headers on the response, and should return either unicode or a string (with encoding already set in an explicit ContentType). Often the unicode is generated by a template. Often, but less often, the template is a ZPT. If calculating data, setting headers, and rendering a template are done in one, two, or X steps, the code here is in charge. We have a variety of approaches to dividing the tasks up, sometimes quite finely. Zope 3 can alternately work like this. This approach is in flux, but illustrates a direction we are going: - (same first step as before:) framework calls your view code, usually with a context object and a request (which has a response). - your code can return any object that provides or can be adapted to IResult, where IResult has a `headers` attribute and a `body` attribute. We've also talked about internal pipelines, where something like the IResult hook might help; or "external" pipelines with a WSGI middleware stack. I hope that helps. I haven't followed this thread very closely for lack of time, and I am nervous that Phil Eby is right that an "official" template spec is going to be exclusive, not inclusive. If someone replies to Chris McDonough's request for summary, perhaps that will also let me and others catch up with the proposals. Gary _______________________________________________ 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
