Jon, Inline below.... Jon Hirschi said the following on 04/07/2011 08:25 PM: > thanks for the reply. > > i don't want it to just stop, what i'd like it to do is to stop > processing the rest of the event. that is the event comes in on one > event but then i need to have it stop processing any of the rest of > the event and only process the new event. > > ie. the normal flow of things is: > request comes in for event "A" > do a search and obtain results, write a report, etc > send response back to requester > > however, if i get a parameter of a certain type, ie searchstring of > "help" what i'd like to do is change the flow so that it doesn't do > the search, or write the report and sends back a different kind of > response. > so that the flow would be more like: > request comes in for event "a" > parameter matches -- announce new event (event b), > send response back to requester > (don't do search or write report) It really sounds like you need write an event-filter. A filter can change the flow of events because it has access to the EventContext directly. Listeners really shouldn't change the flow of the current event that is executing and that is why architecturally (many, many moons ago) that it was decided that listeners don't have direct access to the EventContext. On the nice things about filters is that they accept runtime parameters (see this link):
http://trac.mach-ii.com/machii/wiki/IntroToFilters *Filters return a boolean in order to affect processing of the event.* Returning /true/ will cause the current event to continue processing, while returning /false/ will cause the current event to stop processing immediately and the next event in the queue will start processing. When returning /false/, be sure to announce a new event to reflect the change in the application flow, otherwise nothing will happen. Here's an example of a filter in use that is made to make a decision on what the next event is: <event-handler event="index" access="public"> <filter name="announceByAdminType"> <parameter name="ca,aca,la,ala,system" value="admin.dashboard"/> <parameter name="registrant" value="registrant.dashboard"/> </filter> </event-handler> So you might made a decision event, create an event filter that announces the correct event depending on the "type". > > What i wanted to avoid was having to check in every other listener to > see if that search parameter was help or whether or not the listener > needed to run. the redirect event was working for that purpose, but > then i found out that it's not going to work for the people we need to > integrate with. so i was trying to see if there's an alternative that > doesn't do the 300 redirect. Redirects basically short-circuit the event processing. When a redirect occurs, the current stops and location headers are immediately sent (behind the scenes basically a cflocation occurs). > > My understanding is that if i did an annouceevent and then i did a > cfabort, that it would kill both the new event and the old event. is > that correct? Yes, that is correct. -- Peter J. Farrell pe...@mach-ii.com p...@maestropublishing.com http://blog.maestropublishing.com Identi.ca / Twitter: @maestrofjp -- To post to this group, send email to mach-ii-for-coldfusion@googlegroups.com For more options and to unsubscribe, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://svn.mach-ii.com/machii/ Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
