OMG - Where is the Journal Back Stack?

Topics: Prism v4 - Silverlight 4, Prism v4 - WPF 4
Apr 7, 2014 at 1:26 AM
Edited Apr 7, 2014 at 1:28 AM
I'm coming down the home stretch of converting my substantial WPF application into Prism and I've just hit a major wall. Where is the access to the navigation stack? WPF and Silverlight have a concept of RemoveBackEntry which is critical in any real-life application. Let's say I've just navigated to:


Which is a maintenance page for customers. Now I change the name to 'JohnSmythe'. The URI that I used to navigate to this page is no longer useful and will actually corrupt the navigation because we can't find this resource any more (because the name has changed). Unfortunately, it's still on the navigation stack.

So where is the 'RemoveBackEntry' function and/or access to the journal stack? You can't possibly build a real-life application without being able to remove entries that have been made obsolete.
Apr 7, 2014 at 2:08 AM
OK. Since they don't allow these posts to be deleted, I'll answer my own question. I'm not sure why they left the 'RemoveBackEntry' feature out of the default library, but they have made it rather trivial to override the existing classes. I was able to basically just cut and paste the 'default' version of the RegionNavigationJournal and as long as I gave it an 'IRegionNavigationJournal' alias, the navigation system was able to find it and us it. I simply exposed the Back stack and I was in business.

Again, this is a basic feature. I greatly appreciate the 'lean and mean' consideration, but any real-life application is going to need to examine the forward and backward stacks and remove at least the most recent entry on the back stack. I'd like to hear what the design consideration was to make it private.
Apr 7, 2014 at 6:29 PM
Hi Don,

Thank you for replying the solution you could accomplish. Instead of removing your initial question, it is much better to reply and post your solution because your work would be helpful for users that may go through the same or similar problem.

I think the right anwswer regarding your design question would only be done by the P&P Team. However, based on my understanding I would think that default apps would not need to remove a specific View manually. Furthermore, you would be adding the related responsibility to someone that would not be appropiate.

Regarding the scenario you described, I am afraid I don't completely understand how you would change the View name with the Application running. Any available View that you would be able to Navigate to would have been already loaded and registered in a specific Region. That is why I don't see the problem you mentioned. Plus, I understand that if a View source name is modified, then a rebuild would be needed. Please, let me know if there is something that I missunderstood.

Maybe you could find helpful the Navigation chapter on MSDN Prism's Guide:

I hope I could provide some better understanding about the Region/Navigation Prism design.
Gabriel Ostrowsky.