RE: [coldbox:3362] Re: Dealing with the header buffer and proxy requests

Luis, I think I might agree with you on an interceptor being a good
place for something like this since it keeps it nice and separated from
the core.
I don't think you would want to use the preProcess() interceptor since
the event hasn't been run yet at that point and there's a good chance
the offending code that is dumping things into CF's header buffers
hasn't done so yet. Originally I had said postProcess(), but if I
wanted the option to stuff whatever content was in the header into the
rendered content I would need to have access to the rendered content.
Therefore, I am now actually thinking that preRender() might be the best
place to register an interceptor to do this. It would be called after
all events and the view had been processed but before they were passed
on to the output buffer. Of course, this already has a problem--
Proxies don't fire the preRender and postRender interception points. Is
that on purpose? There's not really any "rendering" that happens in a
proxy if you are using the ProxyReturnCollection setting, but there sort
of is if you are using event.renderData().

My problem is that there is no consistent interception point that is
unilaterally available for both routed requests and proxies that runs
prior to the rendered output being dumped into the output buffer (or
returned) AND has access to the renderData. (I would need access to the
render data if I wanted to append the contents of the header buffer(s)
into it.)

If I just needed it to work for routed requests I would use preRender
since it is your last chance to modify the output before it is placed in
CF's output buffer but that interception point is not fired by proxies.
The only two interception points that a proxy fires AFTER the event has
been run is postEvent and postProcess but those interception points ONLY
have access to the output via the requestContext if renderData is used.
If the content is simply returned from the event it is stored locally in
refLocal.results and not available to the interceptors. Neither of
those interception points would work for routed events anyway since
renderData has already been placed in the output buffer by then. I
really wish proxies gave me preRender to have a final swipe at whatever
data was being sent back right before it was sent.

Hmm, another idea altogether would simply be to provide a utility plugin
with methods for clearHeaderBuffers() and getHeaderBuffers(). That
would let you snag the output of tags like CFAjaxProxy right after you
used them like so:

<cfajaxproxy cfc="pxUser" jsclassname="pxUser">
#headerBufferPlugin.getHeaderBuffers()#<!--- Outputs the auto-generated
JavaScript from the CFAjaxProxy tag --->
<cfset headerBufferPlugin.clearHeaderBuffers()>

Of course, this approach would require manual intervention be the
programmer to reign in the output of said tags every time they used
them.

Thoughts?

~Brad

Hi Brad,

Great observation point. Do you think maybe we should add a preRender() to the proxy, to execute before results are returned? Or maybe a new interception point called:

preProxyResults

so we could easily do result transformations on results?

What you think?

Also, adding those utility methods to the Utilities plugin would be great. Can you post the methods.

Luis

Ok, check this out:

http://ortus.svnrepository.com/coldbox/trac.cgi/ticket/897