[ZPT] response.setHeader() best practice

[Toby Dickenson]

On Wed, 10 Apr 2002 09:41:55 EST5EDT, Alan Kennedy <zpt@xhaus.com>
wrote:

>[Toby wrote]
>> However, your approach signficantly reduces flexibility.=20
>It assumes that the=20
>> textual output will always be directly squashed into 8=20
>bits.=20
>
>Mmmmm, I don't think so. I do assume that it will be=20
>transcoded to whatever encoding the user expects.

Having read what you wrote below, I see my assumption was wrong. You
are assuming that "SAX2 events" is a convenient format for the output
data. If the data is going over the wire then your event handlers
perform encoding.

Trying to match up "layers" in these two approaches; my use of unicode
corresponds to your use of SAX2 events. Do your SAX2 events receive
strings in unicode? If so there is very little difference between the
two models.

>But I am at a loss to think of any "further textual=20
>processing" I might want to do.

....pass the string into a grammar checker, store the result as an
object attribute, or maybe pass it into a module which writes the text
into a banner gif. Im not always calculating a whole document, or
'response'

>There is other processing that I do, e.g. URL rewriting,=20
>HTML element and attribute minimisation, etc, but I do all=20
>that before the output hits the output transcoder, because=20
>the output from my templates is SAX2 events, which pass=20
>through chains of SAX2 filters, with the output/transcoding=20
>step left until very last.

Yes, encoding comes last in both models. You do it incrementally, I do
it in one big hit in ZPublisher.=20

>Keeping the output as structured SAX2 events until the very=20
>last minute eliminates the need for "further textual=20
>processing", i.e. I don't have to go parsing textual HTML=20
>looking for a/@href and form/@action attributes to modify.

Im not sure 'textual' is the right word, but i will use it anyway... I
guess you would perform your textual processing at the SAX2 level?

>But I still stand by my processing model, which avoids both=20
>approaches :-)

One good thing about your model is that you can seperately get at:

1. A method that sets the response headers for character encoding,
sets up the encoder event handler for the right encoding, then passes
the document through the whole system to create the response.

2. The raw SAX2 events. There is no assumption that it is generating a
'response'. Encoding doesnt come into it.  (I would like to get at a
unicode string, not an event stream, but I think that difference is
trivia)

That is very much more than minor philosophy.





Toby Dickenson
tdickenson@geminidataloggers.com