This is definitely something I'll show in future blog posts (actually, my next one after region management will have to take this on) but it's not something I want to put in the core framework - perhaps as an optional assembly like region management.
First, I treat Silverlight applications as applications, not as rich web pages. The navigation framework tries to treat them as web pages even though the so-called SEO doesn't really produce anything readable by search engines. It's just a way to have URLs
that route to views and I can easily do that by processing the query string or URL in my Silverlight app irregardless of a framework.
Second, I believe that things like query string are just an attempt to bridge the gap between a way of thinking from traditional web/ASP.NET development to Silverlight. With Silverlight, there are certainly far better ways to pass information between views
- the querystring is nice and easy because it's what HTML devs are used to, but I personally don't want to treat my Silverlight application like a glorified web app. I'd rather simply persist the values and communicate between view models than have some hack
that looks good in the URL bar but really doesn't serve other purposes.
I also know a lot of examples and code is out there using it - hence why I will show some guidance to integrate it - but most of the enterprise and line of business applications I've worked with don't use that, and instead use other more natural means of
navigation. I'm not sure it is truly as pervasive as people think it is - I think the perception is there, but in working with a lot of different companies, I think most get it and don't use the framework for any number of reasons.
Those are just my thoughts - again, I will address it and have an example of integration - but not something I really want to promote or push because I believe it's the wrong way and haven't found a compelling reason to believe there is true value added
by the navigation framework that's built in.