Bob, it does look like there is no way that I can find to get the actual running event name inside of a runEvent(). If you look in the runEvent() method in the ColdBox controller you’ll see if that event name you’re looking for is contained within the ehBean object, but that is a local variable to that method and is not available inside the event in any way.
I was about to suggest that we place a reference to ehBean in the private request collection, but I’m not sure if that would really be right. For instance, I wouldn’t ever need to know what event was being run inside a handler, because-- well, that’s where I am right now. Perhaps a view might want to know what handler ran it, but handlers don’t really run views when they do event.setView(), the view gets rendered later on the life cycle. Now, it is possible to ask the renderer plugin to render a view directly in a handler, but then again you could technically render a view outside of a handler all-together. The last complication is that you can runEvent() inside a runEvent() which would create a chain of recursive event calls and which one would be in the prc at a given point in time?
I’ll admit I don’t fully understand what it is you are wanting to do. I got a little lost with ‘improve the presentation of the output data with "this part from " and "this other part from " as far as just exactly how you were creating that info.’
If I had to do something like that, I think I would use an interceptor. If your interceptor listens on preEvent and postEvent then it will know what is being run and, assuming it is scoped to the request, it can can maintain the call stack of what is currently running. Add a custom interception point for adding something to your log. Don’t forget that an interceptor has its own stringBuffer you can append to over the course of a request. In your post handler you can retrieve that info from the interceptor and use it. Just a thought…