Getting the full name of the Event while in runEvent()

I have handlers that extend a BaseHandler which contains my
postHandler function. While in the postHandler, I need to determine
the full name (including the handler name) of the event currently
executing. Normally this isn't a problem but if the event is executed
via a runEvent from inside another handler, then getCurrentEvent()
returns the name of the event that ran the event. The action argument
to the postHandler has the correct function name but does not include
the handler. I can do a getMetaData(this) in the postHandler and
tease out the handler name but I hoping to find it somewhere in
ColdBox. Is there a better alternative to getMetaData()?

Bob

index.cfm?event=HandlerA.eventA

BaseHandler.cfc
component {
  function postHandler(event, action, eventArguments) {
    log.info("Hello from postHandler
getCurrentEvent()=#event.getCurrentEvent()# action=#action#");
  }
}

HandlerA.cfc
component extends="BaseHandler" {
  function eventA(event, rc, prc) {
    log.info("Hello from HandlerA.eventA
getCurrentEvent()=#event.getCurrentEvent()#");
    runEvent("HandlerB.eventB");
    return("Hello from HandlerA.eventA
getCurrentEvent()=#event.getCurrentEvent()#");
  }
}

HandlerB.cfc
component extends="BaseHandler" {
  function eventB(event, rc, prc) {
    log.info("Hello from HandlerB.eventB
getCurrentEvent()=#event.getCurrentEvent()#");
    return("Hello from HandlerB.eventB
getCurrentEvent()=#event.getCurrentEvent()#");
  }
}

log entries created:
"Hello from HandlerA.eventA getCurrentEvent()=HandlerA.eventA"
"Hello from HandlerB.eventB getCurrentEvent()=HandlerA.eventA"
"Hello from postHandler getCurrentEvent()=HandlerA.eventA action=eventB"
"Hello from postHandler getCurrentEvent()=HandlerA.eventA action=eventA"

Post is after the handler, do you want to try this with the preHandler and see if you get the same results.

Andrew,

Same results (getCurrentEvent() sees the request event name). BTW,
it's not that I think this is incorrect. In the case of my example,
HandlerA.eventA is, in fact, the current event as far as the request
is concerned but I'm looking for the best way to determine the
handler name of the currently executing event.

logs after adding a preHandler:
"Hello from preHandler getCurrentEvent()=HandlerA.eventA action=eventA"
"Hello from HandlerA.eventA getCurrentEvent()=HandlerA.eventA"
"Hello from preHandler getCurrentEvent()=HandlerA.eventA action=eventB"
"Hello from HandlerB.eventB getCurrentEvent()=HandlerA.eventA"
"Hello from postHandler getCurrentEvent()=HandlerA.eventA action=eventB"
"Hello from postHandler getCurrentEvent()=HandlerA.eventA action=eventA"

Not sure I follow what you are trying to achieve, the currentEvent is the actual current event that will be executed.

btw runEvent I would not really use in a handler unless there is no other way, for example if there is code in that eventB that is required for eventA to complete then it should be refactored to be done in a service.

If you are wanting eventA to invoke eventB then you should be using setNextEvent();

Does that help some more?

Andrew,

My example code is just a simple illustration to show the value of
getCurrentEvent() at various points. In my actual app, I have an
interceptor that, based on certain conditions, will run an event.

So, in my case, you are correct when you say "the currentEvent is the
actual current event that will be executed" if you mean "eventually
executed". That is, it is always the value of the requested event but
not the value of the 'running' event during exectuion of a runEvent().
Again, I don't think getCurrentEvent() is 'wrong'. I'm just for a
getRunningEvent() or some such.

Bob

I think you missed the point of runEvent and setNextEvent.

runEvent is not really considered an actual event, in other words lets say you have a viewlet. This viewlet can be moved or reused across events, then you would use runEvent to get the information that is needed for this view to run succesfully, but by all definitions you are still within the context of the original event.

Does that make a bit more sense.

Andrew,

I think what I'm trying to do isn't too far off your viewlet scenario
but in a non-visual sort of way. This app is an REST api. There is a
'login' event that the client app can run to authenticate. After
authentication, they can run other events. In this case I'm trying to
allow the user to authenticate and run another event in one request.
Basically, the interceptor sees that the user included login
credentials with a non-login request. The interceptor runs the
standard login event and then, if the authentication was successful,
the requested event is run. The results are aggregated by the
postHandler. All of this works great. However, tonight, I was
simply trying to improve the presentation of the output data with
"this part from <eventname>" and "this other part from <eventname>".
I can fudge it to make it work. I just don't want to miss something
that's already in ColdBox.

Bob

Yeah, I think runEvent maybe an oversight when it comes to current events, but by definition the current event is the event that called the runEvent.

I guess Luis, or someone with more knowledge on the runEvent can comment more. But if you are just logging, then there is no harm I guess to say that this even had been run from the current event.

Not sure if that will satisfy your scenario though.

But it sounds like the authentication needs to be an interceptor, which can be intercepted on each event on the REST API.

Not sure how you have this setup, or intend to use it. But if the client is calling an event, then my perception would be that this event would be intercepted to see if they are authorised first.

But having said this I am not sure how you are doing the authentication, or even if you are passing the authentication on each event call. What I mean there is that after the initial authentication, which returns a token that can again be passed with your REST call, which an interceptor can validate.

Feel free to ping me off list if you would like to discuss this in private, but I think here would be better as long as you are not going to discuss anything IP related, as I think others would benefit from this sort of discussion as well.