[4.3.0+188] Is it possible to add fields to the request context via a requestContextDecorator?

CB pretty-newb here. I’d like to add a controllerName field to the request context, just listFirst(rc.event, “.”). A number of bits of code want to know that, and it’s silly to recalculate it everywhere.

I tried creating a requestContextDecorator, but I think I’m missing some of the basics.

Conceptually, I just want to do this

rc.controllerName = listFirst(rc.event, “.”);

I tried this in the configure method of my decorator:

var rc = getRequestContext().getCollection();
if (structKeyExists(rc, “event”))
rc.controllerName = listFirst(rc.event, “.”);

That doesn’t work, because rc is always empty struct, and fields I add there don’t show up in the usual rc passed to controllers.

My guess is that this is because configure() is called too early in the request, before the request context is populated

Is there any way to add fields to the request context that are calculated from rc values?

I also tried creating a getControllerName() method in my decorator component, and accessing it from a view helper that has rc passed into it, but the method isn’t available from there. That’s not ideal, since it recalcs every time. (I know it’s a trivial calculation, optimizing it isn’t important, I’m just trying to understand how this stuff works.)

What’s the recommended best practice here?

For now I’m just doing this in onRequestStart(). I’ll feel like a Luddite, but it works fine old school.

Dave,

If you just want the name of the handler, you can get that with event.getCurrentHandler().

If you need this across multiple events, you might consider creating an interceptor that sets that value - and any others you existing code is looking for.

Other convenience methods would be:

event.getCurrentAction()
event.getCurrentEvent()
event.getCurrentRoutedURL()

Jon

I agree with Jon’s suggested solution first. See if what you need is actually already there. As far as the request context decorator, that’s heavy handed if you just want to populate some default values to be present on every request. The decorator is really for modifying more behaviors. There’s nothing wrong with:

  1. using a request start handler
  2. Tossing in a preProcess interceptor

… and then just setting the values in either one of those places.

Thanks!

~Brad