Microsoft have released the
User Interface Process (UIP) Application Block Version 2. This application block lets you separate out your UI code from your UI navigation code by using a config-driven navigation/workflow system.
I've been using version 1 quite extensively on a project in my day job, and an in-house framework that was pretty similar at my previous company and I recommend you take a look at it if you have any kind of halfway-complex or repeating navigation/workflow.
One caveat - the back button support isn't quite as good in v2 as it could be. V1 had some serious issues with the back button for which I released a fix on the
Got Dot Net community workspace. Having had a quick glance at the v2 source, I'm pleased to see that it looks like they've fixed one of my biggest gripes - namely that an out of order post back used the wrong controller - however three key issues are still present:
- You can't use the same ASP.NET page as the basis for multiple views
- Out-of-order postbacks of the same ASP.NET page are not detected as being an out of order postback
- Out-of-order postbacks (when detected and explicitly allowed) are potentially sent to the wrong nav graph.
In detail, it detects back-button usage by comparing the System.Type of the posted back page with the System.Type of the most-recently-rendered page and uses this to figure out the page's view name. This is where we hit the first issue: You can't have multiple views defined with the same underlying page. I use this scenario quite extensively when I want to have a common page which renders subtly differently in different contexts - for example on a customer details screen the page checks if it's the "new customer details", or the "amend customer details" view, and adjusts itself accordingly. Yes, I could infer this from the NavGraph but then the UI code becomes aware of the navigation, instead of only caring about its own state.
Secondly, the post back is handled by the most recent navgraph. Hence if your view is used in multiple navigation graphs (eg the 'new customer' and the 'amend details' nav graphs) then you're going to suddenly launch into the wrong navgraph if you use the 'back' button to get to a view used in an old navgraph. The UIP block does check that the view exists in the current nav graph, which seems to me to be a half hearted compromise. If you are doing context-sensitive navigation - for example by having a 'next' button for new customer but an 'update' button for amendments then Stuff will still break.
Finally, and as should be obvious from the above, the system can't detect that you're an out of order postback when you use the back button and post back a page of the same System.Type as the most recently rendered page.
So all in all the V2 release is better than the V1 release in terms of back button support, but still leaves a lot to be desired for my particular scenario. I'll try to get an enhanced back button support release together for V2 as soon as I can.