Struggling with overrideEvent() (v2.63)

We are utilizing an interceptor to detect certain event names and, for
certain scenarios, perform an overrideEvent(). We have a great many
runEvent() calls throughout our application.

In the Coldbox controller.cfc, v2.63, function "runEvent", line 411:
<!--- Verify if event was overridden --->
<cfif (arguments.default) and (arguments.event neq

This line fires *after* the preEvent interception call. We have, in
the preEvent interception point, performed overrideEvent(). However,
because of the "arguments.default" condition, which defaults to false,
the controller doesn't repopulate the oEventHandlerBean and
oEventHandler objects on line 414 and416, respectively. Therefore,
the event isn't *really* overridden, just the name in the event, not
what the runEvent() command actually tries to process.

We tried fiddling with the flag, but on some occasions, even though
this is the last interceptor in the chain, we would get errors about
things not being available in the rc that we had set in prior
interception points. To be clear, the other interception points are
all preProcess, whereas this one is preEvent.

preEvent runs for each individual runEvent call that is executed. I
would say that it seems that preEvent fires before preProcess, but I
can't really nail it down.

Am I missing something about the way overrideEvent() is supposed to
work and why this condition of arguments.default is affecting it? (We
cannot pass in that arg as "true" because our call is to the one in
frameworkSuperType, not the one directly in the controller.)

- Will B.

preProcess runs first, then preEvent can run on ANY event execution.
The override event ONLY works when you are overriding the main
incoming event, because if not, there would be no way to trak event
executions. Override event means you programmatically switch the
event in the request context set for execution.

Well, unfortunately I'm not sure what you mean by "keeping track of
event execution".

We have:

Primary event, from the URL of:

It does some RC setup then sets a view. Now, if that view has content
that's dependent on customized code, or not, we're not sure yet.

The view says:

The interceptor for preEvent says:
Hmmm....I know that the current client here is ABC. So I'll run the
normal /handler/test.viewletHeader function, by not performing an
overrideEvent call at all.
But it MIGHT say:
Hmmm.....the current client is XYZ, so let's do overrideEvent
('clients.XYZ.test.viewletHeader) handler event.

When the runEvent interception point returns to the Coldbox
controller, the controller says "Let's see if the event is changed and
if so, load up the handler/method beans so I can execute
them." (Obviously with the caveat of "unless this arguments.default
flag is false", which is most of the time.)

In this scenario, we had TWO events executing...the main event from
the URL of test.primaryEvent and also the inner viewlet event that
needed redirecting to show the right output of test.viewletHeader.

Loathe as we were to do it, we put a hack into the controller (seeing
as how 2.63 isn't likely to receive any new updates for a while, if at
all) of detecting the presence of rc.cbHackForceOverride. This flag,
if present (and set from the preEvent interceptor if applicable)
allows the controller to load up new handler and method beans.

We haven't been able to detect anything bad as of yet. The stack
trace in CF looks good, the CB Debug output shows a valid stack trace
(in the expando areas like cache, etc.).

Any further thoughts for us? (Pretty sure the initial idea for
overriding the events came from a really smart Coldbox guy anyway!)

- Will B.

Will, I don’t recommend hacking the core for this. You can go around it like I explained by creating a facade method that does your lookup for you: runMappedEvent(), so it can do the customized searching. Instead of hacking the core to take advantage of overrides, when overrides or for main event executions ONLY.