State passed in URL

Jun 14, 2012 at 8:06 PM

So far I love what I am seeing here.  I am gettting ready to embark on some sample/test projects to continue to evaluate how this framework could help me.  Though for some reason, passing the navigation/transition state information in the url isn't sitting well with me - I prefer clean, logical URLs.  I worry about large/complex dialogs with many states and transitions.  Do you have any words to calm my fears :) ?

Coordinator
Jun 14, 2012 at 10:30 PM
Edited Jun 14, 2012 at 11:25 PM

Thanks for an interesting question. I can understand where you're coming from but don't worry, the Navigation framework can be used in lots of different ways.

If you don't want to pass navigation/transition state information in the URL then you can set trackCrumbTrail="false" against each State in the StateInfo configuration. This would mean URLs would be completely clean, but be aware that back navigation then can't be used.

If you want logical URLs, the Navigation framework supports ASP.NET Routing. You can specify a route against each State in the stateInfo configuration.

<state key="s1" page="~/p1.aspx" route="r1" trackCrumbTrail="false"/>

It can even help you build Single Page Applications, where there is only one state and no transitions.

Let me know if you're still interested. If you need any clarification or have more questions, please just ask. Also, I could point you at some sample code/articles I've written that should help.

Jun 16, 2012 at 5:40 PM
Edited Jun 16, 2012 at 5:40 PM

Let me start by saying that I love your two articles in the MSDN Magazine - very fresh perspective! I have created one VS'10 solution per article to get a taste of the Navigation framework.

The URL Query for back navigation is a strange choice for just about _any_ type of app. I work in the healthcare industry and seeing patient's provided information that can be easily modified across several steps of the wizard seems unacceptable. Even any trivial tax preparation app, or college admissions or .. you get the point. So this is only useful for some code prototyping or home projects.

Removing the crumbs (trackCrumbTrail=false) as you suggested renders the framework nearly useless. What if I am prepared to prevent the user from opening multiple browser windows in order for the Navigation framework to store state in Session object, is there a built in support for that?

Great Start!!

Coordinator
Jun 16, 2012 at 7:16 PM

It's great to hear you enjoyed the articles and thanks for sharing your concerns about the Navigation framework. Let's see if I can allay them.

When writing the MSDN articles I tried to come up with a sample project that demonstrated the different features of the framework in a straightforward way; but I agree with you that it wouldn't be appropriate to build a real online Survey in that way. However, that doesn't mean the Navigation framework can't still be used. The way to build a real Survey application would be to store the answers, as you say, in Session, but to still use the Navigation framework to handle the forward and back navigation. In that case, only the previous State(s) would appear in the URL and not the user's data.

I've taken this a stage further in applications I've written by storing the data in Session but still allowing the user to open multiple windows/tabs. The way I've done this is to maintain an id in StateContext Data that points to the specific instance of the user's data in the Session. Then it's just this id (and previous States) that appears in the URL and not the user's data. That way, you can have multiple instances of the user's data allowing them to complete two surveys simultaneously in different windows.

If you prefer, you can even configure the framework so that the crumb trail is stored in Sesssion rather than the URL or write your own custom crumb trail storage mechanism.

I agree that removing the crumbs is pointless if you want to make use of back navigation. However, there's more to the Navigation framework than back navigation. For example, it's really useful in building Single Page Applications where there's no point in having the crumbs in the URL.

I hope this gives you the idea that the Navigaiton framework has a lot more about it than I could explain in the articles and I look forward to hearing what you think.

May 29, 2013 at 3:45 AM
Edited May 29, 2013 at 3:45 AM
Graham, do you have an example of storing this in Session as opposed to the StateContext?
Coordinator
May 29, 2013 at 7:56 PM
Edited May 29, 2013 at 8:03 PM
That's a good question. I'll take the example of the survey from the magazine article where we have two Questions and want to pass the answer from the first question to the second. Instead of passing the answer in NavigationData as demonstrated in the article, we'll store the answer in Session and only use the Navigation framework to move to the next State:
Session["technology"] = Answer.SelectedValue;
StateController.Navigate("Next");
That's the first option. If we wanted to allow the user to open multiple windows/tabs and fill in two different surveys at the same time then in the Question1 State we'd create an ID in StateContext data:
StateContext.Data["ID"] = Guid.NewGuid().ToString();
Then it's this ID that we'd pass around in NavigationData when moving between States:
NavigationData data = new NavigationData();
data["ID"] = StateContext.Data["ID"];
StateController.Navigate("Next", data);
That way we can store the survey answers in a Session object against this ID:
List<string, string> survey = new List<string, string>();
survey["technology"] = Answer.SelectedValue;
Session[(string) StateContext.Data["Id"]] = survey;
So if there were two windows/tabs each one would have its own ID and so each would have its own separate set of answers. I'm always happy to help so let me know how you get on.
May 29, 2013 at 11:47 PM
Perfect! Thanks - I had implemented it this way but wanted to see if I was going down the same track. Always good to see different ways (or in this case, similar ways) to 'skin the cat'...

Poor cat!