Event Listeners

[Brett]

I'm just digging in and was playing with event listeners described
here:

http://bears-eat-beets.blogspot.com/2010/04/coldmvc-event-listeners.html

Couple observations that I wasn't sure about.

1) A controller's requestStart events fires after execution of the
request not at the start. It appears that coldSpring initially wires
the ColdMVC and then any event from annotations to the end of the
stack so the request will be handled before an annotated requestStart
events. Is this intended? Should we be using preRequest then? (not
mentioned in the blog post)

2) actionStart and actionEnd don't appear to be implemented but are
mentioned in the blog post. Have these been removed?

thanks,

.brett

[Tony Nelson]

Brett,

As far as I know, you're the first to actually dig into the event
handlers, so there are probably some improvements that could be made.
I'll try to answer your questions as best I can.

1) There are a couple default ColdMVC event listeners defined for the
requestStart event, namely:

* modelInjector.clearCache()
* scopeManager.addScopes()
* helperManager.addHelpers()
* tagManager.generateTags()
* renderer.generateTemplates()
* paramManager.populateParams()
* flashManager.startRequest()
* filterManager.enableFilters()
* routeHandler.handleRequest()

These events exist to make sure the framework is ready to handle your
request. After these listeners have executed, ColdMVC will execute all
of your application's methods annotated with @events requestStart. As
far as I can tell, you've figured all this out for yourself already.
The preRequest event exists only to fire
metaDataObserver.findObservers(), which will scan your application's
components and find any methods that are expecting to listen for the
requestStart event. If the metaDataObserver was set to listen for
requestStart rather than preRequest, your applicant's event listeners
wouldn't be discovered in time to execute during the requestStart
event. Hopefully that makes some sense. I like to think of the
preRequest event as a private event intended for use by the framework
only. I guess I could move all of the ColdMVC requestStart event
listeners to listen for the preRequest event instead if that would
help eliminate some confusion.

As far as the controller's requestStart events firing after the
execution of the event, I'm a little confused. Can you explain your
scenario a little more? I typically think of the actual "request" as
calling the action then rendering the layout and view.

2) About 2 weeks ago I spent some time cleaning up the event listeners
and in doing so I removed the actionStart and actionEnd events in
favor of preAction and postAction, since they're essentially the same.
A typical request will now broadcast the following events:

* requestStart
* preAction
* preAction:{controller}Controller
* preAction:{controller}Controller.{action}
* postAction:{controller}Controller.{action}
* postAction:{controller}Controller
* postAction
* preLayout
* preLayout:layoutController
* preLayout:layoutController.{layout}
* postLayout:layoutController.{layout}
* postLayout:layoutController
* postLayout
* preView
* preView:{view}.cfm
* postView:{view}.cfm
* postView
* requestEnd

I guess I could still clean up that list a little bit, since preLayout
and preLayout:layoutController are basically the same thing...

Sorry for the confusion. Hopefully that somewhat helps. If you have
any other questions let me know.

Thanks for checking out ColdMVC!

-Tony

[Brett]

Thanks for the reply Tony, that all makes sense.

The issue I found is that requestStart gets called after postView(and
other controller and view events), because the default ColdMVC event
routeHandler.handleRequest() is called in the event stack before any
annotated events. So routeHandler.handleRequest() ends up calling all
the controller & action events and calling the controller.action()
before getting to the annotated requestStart event.

Here is a test case, add these two functions to a controller and then
call it:

/**
* @events requestStart
*/
function testRequestStart() {
writeDump("request start called");
}

/**
* @events preAction
*/
function testPreAction() {
writeDump("pre action called");
}

testPreAction gets called before requestStart.

I think the fix for this might be to break up the default ColdMVC
events into "private" events and keep the public events clear of any
system functionality as you suggested.

Great job on the framework, btw, really liking it so far. More
questions sure to follow.

thanks,

.brett

[Tony Nelson]

Ok so I re-thought about what you wrote and it starting making more
sense, so I made some updates that will hopefully make the
requestStart event more useful. Here's what will typically execute
now:

preRequest:
* metaDataObserver.findObservers()

* modelInjector.clearCache()
* scopeManager.addScopes()
* helperManager.addHelpers()
* tagManager.generateTags()
* renderer.generateTemplates()
* paramManager.populateParams()
* flashManager.startRequest()
* filterManager.enableFilters()
* routeHandler.handleRequest()

requestStart:
* [ your application's listeners ]
request:
* routeDispatcher.dispatchRoute()

To summarize, I made it so the ColdMVC event listeners will be
executed during the preRequest event, then any of your applicant's
listeners will execute during the requestStart event. At this point,
the event (controller, action, view) will be populated, so you could
manipulate the values before routeDispatcher.dispatchRoute() actually
invokes the action during the newly created "request" event.

Hopefully that clears things up a bit and allows interceptors to be a
little more powerful.

-Tony

[Tony Nelson]

It seems we were replying at the same time... :).

Thanks for your explanation. Hopefully we came to the same conclusion
of how things should work.

-Tony

[Brett]

Yep we got to the same conclusion. Looks good, I'll pull your
changes.

thanks.

.brett