Add redirectEvent for filters/plugins

[jorgeloyo.accounts@…]

I have numerous event-handler's that perform a simple redirect.

<event-handler event="goHome" access="public">
   <redirect event="home"/>
</event-handler>

To avoid the number of this type of event-handler's I decided to create a generic event-handler:

<event-handler event="redirectEvent" access="public">
   <filter event="redirectFilter"/>
</event-handler>

In the filter I use <cflocation> and BuildUrl() to go where I want.

Although this works great, this method leaves out one nifty feature available when using the <redirect> in the controller, which is the ability to persist arguments.

I was wondering whether or not it would be helpful to include a "redirectEvent" method to the MachII.framework.BaseComponent so that the full feature would be available from a plugin/filter.

[peterfarrell]

We've discussed this the past quite a lot during team discussions. However I'm wary to add something like this because it hides the flow of your application because it's no longer in the xml. Definitely something to think about for 2.0.

In the mean time, your custom filter can leverage the API that is available for persisting data across a redirect.

<cfset PersisId = GetAppManager().getRequestManager().savePersistEvent(eventArgs) />

Be sure to append the persistId as url parameter in your cflocation or Mach-II won't be able to pick it up on the other side of the redirect.

[peterfarrell]

• Assigned to version 2.0 for consideration

[anonymous]

For the record. In 1.6 that internal API call has been renamed to:

GetAppManager().getRequestManager().savePersistEventData(eventArgs);

The joys of undocumented calls. ;)

[brianfitzgerald]

I was just came across this as I was writing up my own enhancement request ... which was to make something like this not only available to plugins and filters, but also listeners, by adding redirect() to the BaseComponent, right alongside announceEvent(), with a second argument to determine whether or not to copy all the event args over to the new request.

if(success) {

redirect("showAdminMain", true);

}

otherwise, if we just wanted to copy a few event args, we could specify a third argument with a list of those args to persist

if(success) {

redirect("showAdminMain", false, "message,resultObj");

} else {

redirect("showUserForm", true);

}

I know there are some concerns around this, as well as some other ideas in the works for redirects - just thought I would throw this out there.

[peterfarrell]

Guys, I think we should address this specific issue for Mach-II 1.8 since we did code name it "simplicity". Does that sound like a good idea?

If we decided yes, who would like to tackle the spec and details?

[kurtwiersma]

I think this would go with our theme of making things simpler. Brian would you like to write up a spec?

[anonymous]

Hey Kurt,

I'd be glad to knock that out ... just because "spec" could be interpreted in a number of ways regarding level of detail, can you link me to a sample of a past spec which I should model it after?

Thanks, Brian

[kurtwiersma]

Check out SES Improvements as an example of a Mach II Spec.

[brianfitzgerald]

I have written a rough spec for the enhanced redirect functionality ... open for feedback.

I'll go ahead and say this in advance, just because I would really like to see this method available from within listeners. I know the argument in the past has been that you will do yourself a disservice by using this sort of functionality within a listener because you will hide the flow of the application outside of the mach-ii.xml comfiguration file.

This would certainly be a valid concern, BUT, couldn't event-mappings be used to keep the flow from being hidden? In other words, just as we use the value of a specified event-mapping when we call announceEvent() in a listener, couldn't we do the same thing with redirectEvent(), thereby not hiding the application flow inside the listener?

[peterfarrell]

Just wanted to answer Brian's questions on the ticket for posterity. Yes, a redirectEvent() method should obey event-mappings as well. It would be just as easy for somebody to hide the flow of the application in a listener by hard-coding the event name in there instead of using an event-mapping. So I will admit that this argument I've used in the past is flimsy at best right now. I whole-heartedly believe that is a good addition to the framework.

[peterfarrell]

Brian, I think that we will need to support the new URL routes feature as well for this. Check out SES Improvements to see what I mean. Routes are unique across the base app and all modules so I think we are safe with adding a method like redirectRoute(). Right now it looks like we'll be adding a redirectEvent and redirectRoute to the EventContext with methods redirectEvent, redirectEventInModule and redirectRoute in the BaseComponent (which ultimately just call the methods in the EventContext).

[peterfarrell]

Since Kurt is working on the EE enhancements on the <redirect> command, he's going to take this ticket on. Since I investigated how to do this, here's the run down:

• The BaseComponent needs redirectEvent() (which uses the current module name - similar to announceEvent), redirectEventInModule() and redirectRoute() methods
• The EventContext needs redirectEvent() (which takes both module and event name -- just like EventContext's announceEvent) and redirectRoute() methods
• The machinery in RedirectCommands needs to be refactored into the RequestManager
• The RedirectCommand will look more like the AnnounceCommand in which that it calls arguments.eventContext.redirectEvent() or arguments.eventContext.redirectRoute() depending if the redirect is an event or route
• Basically it seems like you need to able to create a redirect command from the event context just like how the AnnounceCommand calls the announceEvent() method in the EventContext
• The RedirectCommand look more basic and only holds the attribute values and builds persistargs etc. to pass into the redirectEvent() method in the EventContext

[kurtwiersma]

mylyn/context/zip

[kurtwiersma]

Current CFEclipse context for implementing this feature

[kurtwiersma]

Added redirectEvent, redirectUrl, redirectRoute, and redirectEventInModule methods for filters, plugins, and listeners. closes #30