Design pattern(s) for a webservice enabled telerik treeview for navigation of a document site

Question

I am currently working on a document management system in ASP.NET 3.5 using the Telerik AJAX toolkit. It consists of masterpage with a title banner across the top and a RadTreeview down the left hand side for navigation through the site. The treeview uses a combination of static nodes and dynamic ones. The dynamic nodes are populated via a webservice. When a node is clicked the relevant page is navigated to, reloading the masterpage and displaying the content of the target page.

The problem comes from the fact the treeview's dynamic nodes are populated via a webservice and therefore as the user navigates through the tree to find a document the treeview behaves as you would expect. However, when you get to the bottom of a tree of dynamic nodes the navigation to the page of the navigateurl causes the relevant page to be loaded and then the treeview resets itself to a collapsed state. This means the user could be deep in a nest of documents but when they view one, the tree collapses and they have to start their navigation all over again. This limitation is not going to be acceptable from an ease of use perspective.

According to Telerik, this is the designed behaviour for performance reasons - the node only ever worries about populating the next set of nodes and therefore the treeviews state is not remembered in viewstate.

So, the meat of question is...

Is the masterpage/async treeview navigation design pattern a valid one?

Are there any other ways to have an ajax treeview on a masterpage, that remembers it's state when another page is navigated to?

I have considered a siglepage/updatepanel/partial page rendering model but the opinions I've seen on the net infer that this is bad idea. It confuses users that expect back/forward browser behaviour to navigate through the site but in a single page world they would end up leaving the site.

I also thought that maybe using a single page container and an iframe may work but this seems to be moving away from the "standard" design pattern of using masterpages.

Answer 1

If the treeview is going to collapse every time the user is navigating to another page/node, it is going to annoy the hell out of them. It is not acceptable from an end-users perspective if they are going to make more than at most two rounds at it.

I would say that it is very good that you uses good old pages if the users are going to bookmark and/or send links to the different parts of the application, or especially if you want Google, Yahoo! et.c. to index your application. Else you can use an IFrame / #hash-link combination for your application; the IFrame can generate history events, thus forward and backward navigation even if the user is on the same top-page.

On the state for the treeview you can use localstorage for the most browsers to store the current state including all the data, for other browsers you can use "Flash cookies", which allows for storage up to 100kb.