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

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

I personally would see greater value in a consistently named
interception point across both routed events as well as proxied events
so you had a singular place to do last minute changes. Of course, I
THINK routed request only have string output whereas a proxy may return
an array or struct etc. (I might be wrong) Any interceptor would need to
test the renderData to see what it was working with.

So, I would be in favor of adding preRender to the proxies. Of course,
you wouldn't really be able to do a postRender, since the proxy exists
with a return statement. Perhaps preRender could happen after the event
had been run and postRender would run after the data had been marshalled
(if applicable).

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

Yeah. A couple of the Railo/Blue Dragon examples came from the Model
Glue code base. Will there be any problems snagging their code for our
framework?

~Brad

Hi Brad,

it actually isn’t being rendered so adding a preRender on the proxy doesn’t make sense in my opinion. I added a preProxyResults as it is more descriptive of the interception point. It passed the full refLocal scope as the proxyResults struct. So you can manipulate and see all the proxy execution stuff and modify it.

As for the latter, maybe we can see if there is something in cflib and look at the licenses. If not, I will research the pageContext() and do it manually.