[ZPT] response.setHeader() best practice

[Toby Dickenson]

On Tuesday 09 April 2002 8:39 pm, Alan Kennedy wrote:

>Moreover, I believe the most efficient way to deal with
>multiple character encodings is to decide the character
>encoding before template evaluation begins, and transcode
>the output of the template as it is generated.

I dont know about *most* efficient.... all of the proposed solutions seem to 
be efficient enough. Even done badly, its hard to waste processor time on 
something as simple as character encoding.

However, your approach signficantly reduces flexibility. It assumes that the 
textual output will always be directly squashed into 8 bits. It is not 
uncommon to perform further textual processing on the output of presentation 
logic, and having the output as unicode is the most appropriate option.

(As I said, Im not using ZPT in anger yet. ZPT might be different)

>However, in Zope (as far as I understand it) the developer
>only gets to control the output from *inside* the TAL
>template, since that is the only place where they can put
>functionality, or at least it is the easiest place to put
>functionality.

>Given this (pseudo?)restriction, it does make sense to
>provide the developer with the ability to modify the HTTP
>response from within the template. But I'm fairly sure that
>I don't like the "procedural" approach of
>doing "response.setHeader()".

There are other areas in Zope where a method has this dual personality. Its 
main job is to calculate a string, perform a management task, or whatever, 
but it also has to do something extra with the REQUEST or RESPONSE if it is 
the top level published method.

The most common use of this in the Zope source is management methods calling 
RESPONSE.redirect only if they are the top level published method.

>Provide a special TAL command for specifying output
>parameters

Merging the two personalities I mentioned above would be traditional for 
Zope, but it has proved to be problematic. Separation is good.