It’s one of those common problems that pop up when doing web development. The stakeholders pose the need to redirect to another page if some condition isn’t met. One example might be… When a customer has not accepted our privacy policy and browses to a page that requires authentication, ensure first that they accept the privacy policy.

There are many ways this problem can be solved and one way is to always redirect them to a page for the privacy policy.

I’ll describe how we thought about this solution and how things have changed, finally showing the ideal solution (although not quite baked yet).

Coming from ASP.NET MVC

The common approach would be to introduce an ActionFilter. When we first went down this path this meant you needed to have an attribute on each action / controller that needed this behavior. This got a bit ceremonial, and additionally it required you to remember to register your action filters as you added new routes. I realize since then they have added action filters that can be applied globally and that would have helped.

The additional pain point that likely can crop up with this solution is what happens when the business says that they no longer want to redirect to another page, they want to show a modal dialog to the user?

Now I have to say this post is not a FubuMVC vs. ASP.NET MVC post. I am literally describing the experience we’ve had with this type of requirement from both perspectives. Obviously, I am a bit biased now that we have moved to FubuMVC and we have made the switch for reasons that make sense for us. If you’re not there, great. This isn’t a sales pitch and you can stay happy in your own bubble and I’ll stay happy in mine. I digress…

FubuMVC Solution #1

Early on in our transition to FubuMVC our first thoughts went something like this. “What’s the equivalent of an ActionFilter in FubuMVC? Behaviors, great!” and a solution was created that was very similar to an ActionFilter.

Here is a sample of what that solution might look like.

Now although there’s a lot going on in this class. It does bring with it the advantage of conventional wireup as shown below.

The disadvantages it brings using this solution is testing is a bit involved (although arguably less so than before). Continuations in FubuMVC are also conventional and we have lost this using the IContinuationDirector directly in our code.

FubuMVC Final Solution

Discussing things with Jeremy Miller while I was upgrading one of our projects to the latest version he suggested that I use more than one controller for the same route (or chain in Fubu terms). Huh? Coming from my previous experience this one threw me for a loop. Trusting in his advice I decided to give it a try.

Here is the final solution with some caveats for the not quite baked part. Having an InputModel of a different type on the same chain causes problems with partials, and the fubu diagnostics pages that detail your routes are confused and display these actions rather than the primary controller’s action. These issues will soon be remedied and I will update the post when it does. For now, you can just inject the IFubuRequest again rather than taking an argument for the action.

Here is what this solution might look like.

I think the sample speaks for itself. It’s obviously easier to test, and now we aren’t losing OOTB conventions around FubuContinuation. One scenario this would be useful. Say an AJAX rendered module on a page is the piece requiring authentication. The conventions can leverage a FubuContinuation during an AJAX request and return JSON data to the client indicating a redirect should occur, or possibly render a modal dialog as I mentioned before.

I hope this post has been helpful, with more posts coming soon. If you have questions, feel free to leave a comment, or post to the group. The community is quick to respond.