Re: Post processing

After looking at it a bit during my train ride home, I think there are
three ways to go, two of them minor variants of the same idea and both
very easy to implement, the third a bit harder and very possibly not
worth implementing.

The first idea is similar to what Adam proposed -- adding a hook that
would contain filters that could modify the response.  However, if you
have filters, you might want to have several acting in series, so you
couldn't use the present Hook or KeyedHook's return value as a way of
implementing that, as returning something stops the hook; you'd have
to separate making and saving a modification of the response from
stopping the hook.  That's easy -- just put the response temporarily
in the session dictionary (session here in the requestHandler sense,
not the sessionHandler sense).  

If you are doing that, you have two options.  1) Rewrite web.protocol
and templating.Handler a tad so that that is how the response is
gotten out of HandleRequest in the first place.  (Currently,
HandleRequest returns the response, but it could simply run and then
the web service could look for the response in the sessionDict.)  The
current hook functions in HandleRequest wouldn't return anything, but
wouldn't do anything either if a response had already been deposited
in the sessionDict.  If this were to be done, response filters could
simply be appended to HandleRequest after templating's functions, and
there would be no need to add any new hook anywhere.  However, this
approach might break some code out there that I don't know about.  2)
Leave HandleRequest alone, and add another hook to web.protocol just
to process the response.  It would be empty by default.  The response
would be put in the sessionDict before the hook and taken out
afterwards.  This wouldn't break any code, and would probably be
cleaner, although I feel conservative about adding hooks.  (Even an
empty hook takes a little time each request to do its little bit of
nothing for you.  Add a lot of nothing together, and you have too much
of it.)  Also, I'm inclined to think that such a hook should be a
Hook, not a KeyedHook, as what filters you use is probably largely
independent of how you got a response to filter (you could always look
at Configuration.job inside the hook function if you cared, in any
case).

The third approach would be to implement some kind of subrequest or
servlet chain/pipeline mechanism, which would probably require major
rejiggering of how the request cycle currently works.  

So, my inclination would be to add a ProcessRequest hook to
web.protocol, to maintain backwards compatibility and just to keep
filters conceptually separate from the initial generators of
responses.  I've tested this, and if it will work for Adam and no one
has any objections or ideas for something better, I'll check it in.

Speak now, or forever hold, etc.

js


On Wed, Dec 17, 2003 at 05:27:17PM -0500, Jacob Smullyan wrote:
> On Wed, Dec 17, 2003 at 11:12:45AM -0500, Adam DePrince, CSA wrote:
> > There is currently no clean way of catching the output of templating and
> > applying some sort of post processing filter.  I'd added PostProcess
> > hook to templating.Handler that allows you to modify the outgoing data. 
> > 
> > My motivation was my own itch.  I needed created a way of removing \n's
> > from the html generated by skunkweb.  Instead of using spool I figured
> > that in one effort I would:
> > 
> > 1. Document and provide a "how to" example on writing a service 
> > 2. To do #1 I wanted to provide something useful, but simple to write,
> > like an outgoing filtering module.
> > 
> > I'm hoping that skunkweb-3.5b5.template-postprocess-hook.patch would be
> > accepted into the skunk sources.  
> 
> I'm definitely agree that post-processing should be easier to do.
> What you've done seems very straightforward.  But it has one drawback
> -- it only applies the filter to content that emerges from that
> particular handler.  I'd prefer the filter functionality to be more
> general.   I'm in a rush right now, but I'll write more about it
> later.  In the meantime, if anyone wants to sound off on the topic of
> filters, subrequests, or what have you, this is your opportunity....
> 
> j

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4R5wuqamFyFXXLIRAgdVAJ9L+zO567TzbiJqfWzXMVJ507ealwCcD36g
dmTIDyj/izyIl7X6GhLtmiE=
=JYn1
-----END PGP SIGNATURE-----