MS Application Blocks

Back Button Patch for UI Process Block v2

Duncan Millard — Fri, 14 May 2004 07:02:00 GMT

"SpideyWitness" has ported my back button fix to version 2 of the User Interface Process Block. Top man!

I haven't had a chance to check it out yet, but he has kindly emailed me the source so I'll have a look soon.

UI Process Block: Let me help you

Duncan Millard — Tue, 04 May 2004 12:41:00 GMT

I've noticed a number of referrals from Google from people looking for help with the UI Process block.

Having spent some time with the UI Process Block I'd like to share my experiences, but to do that I would like to know what information people are after. Please leave me a comment below, or contact me directly using the "Contact" link above and I'll try to come up with some suitable articles.

Finally the obligatory plug: If you are looking for help with UI Process Block implementation, especially on projects that also involve BizTalk, my employer (www.solidsoft.com) specialises in BizTalk and .NET implementations so feel free to make an approach to learn more about us and (I hope) engage us commercially.

IMPORTANT UPDATE: I haven't worked with the UI Process Block for almost a year, so it's increasingly hard to devote time to looking into these issues. Please feel free to continue using my comments section to ask questions - but it's unlikely that I'll be able to chip in with answers. Don't forget the Got Dot Net workspace.

IMPORTANT UPDATE #2: I've now closed comments on this entry; please direct your questions to the official Got Dot Net workspace.

IMPORTANT UPDATE #3 :): Closing comments meant they weren't displayed any more; that was unintentional and seems to be a limitation of the .Text blog engine. Comments are open again so that you can see the old content :).

User Interface Process Block v2 and Back Button Issues

Duncan Millard — Mon, 26 Apr 2004 11:39:00 GMT

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.