[ZPT] response.setHeader() best practice

Tue, 9 Apr 2002 14:39:33 EST5EDT

Overall viewpoint: My view on these issues is that the 
document cannot control its own metadata. I say this for 
the following reasons.

There is simply some meta-data which by definition 
(assuming a recursive descent evaluation of the template) 
cannot be known during evaluation of the document. This 
includes

1. Content-Length. The final length of the content cannot 
be known until the document is fully evaluated.
2. Content-MD5. A checksum-style integrity check, cannot be 
known for same reason.

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 say this because that's exactly what I am doing (I am 
using TAL outside of Zope). But this means that I have to 
write (simple) server side code to set up a transcoding 
output channel/buffer. This also means that I can do nice 
things after the template evaluation is finished, e.g. gzip 
compression.

In this scenario, by the time the first character comes out 
of the template, it is already too late to change the 
character encoding. But this suits me fine, since the 
server side code is the only code that gets exposed to the 
original HTTP request, and thus the only code in a position 
to know the language and character set which is acceptable 
to the requester.

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()".

So here is one potential alternative.

Provide a special TAL command for specifying output 
parameters, which is directly analogous to the HTML 
<meta/@http-equiv> approach. Possible names for this 
command could be

1. tal:meta
2. tal:output (stolen from XSLT)
3. tal:http-equiv

The mention of XSLT is not incidental. I see TAL and XSLT 
as two sides of the same coin. See 
http://www.w3.org/TR/xslt#output for more details of XSLT 
handles output.

The structure of this command would be similar to the 
tal:define and tal:attributes commands. Here are some 
examples (namespace declarations omitted for clarity)

A: <html tal:output="content-type string:text/html;charset 
string:iso-8859-7">

B: <html tal:output="method string:html;version 
string:4.0;output-xml-decl false;output-dtd-decl true">

I think you get the idea.

While the concept is exactly the same as "response.setHeader
()", the declarative approach seems cleaner to me.

Just some thoughts.

Alan Kennedy.

---------------------------------------------
This message was sent using WebMail by CyberGate.
http://www.gate.net/webmail