UpdatePanels und Browser-Back-Forward-Buttons

by Anton 9. April 2010 21:12

Auf einer Seite X mit UpdatePanels konnte man via asynchronen Postbacks Veränderungen vornehmen. Andere UpdatePanels wurden so aktualisiert – zum Beispiel die Anzeige des Inhalts eines Warenkorbs. Wenn man nun aber von der Seite wegsurft und danach versucht mittels des Browser-Back-Buttons wieder zurück zur Seite X zu gelangen, erreicht man diese natürlich, jedoch sind die Controls in den UpdatePanels nicht in dem Zustand, in denen man sie das letzte Mal gesehen hat. Die Inhalte sind auf dem Stand, auf dem sie waren, als man die Seite X das letzte Mal vollständig geladen hat.

Das allgemeine Problem

Dieses Problem ist gut bekannt als AJAX-Back-Button-Problem. Man findet im Internet viele Problemerörterungen. Hier ein paar Links zum Einstieg:

Viele Lösungen

Eine weitere Suche im Internet ergab eine Vielzahl von Möglichkeiten, um des Problems Herr zu werden. Falls ich nichts übersehen habe, so wird in allen Fällen ein Hash an die URL gehangen. Als erstes lachte mich Really Simple History (RSH) an, aber das Projekt hat schon eine Weile keine Aktualisierungen mehr erfahren. Dann bin ich noch UpdateControls begegnet, die wohl aber auch nur solange genutzt wurden, solange es noch kein ASP.NET AJAX 3.5 gab. Mit letzterem wurden dem ScriptManager einige Funktionalitäten (u.a. AddHistoryPoint-Methode und Navigate-Event) mitgegeben, die dieses Problem ansprechen und auch lösen. Hier die besten Seiten, die das Prinzip beschreiben und gute Anleitungen sind:

Für jQuery wurden auch schon etliche Implementationen entwickelt, die das Problem lösen.

Wir haben die HistoryPoints-Funktionalität implementiert, so dass beim Verändern des Inhalts des Warenkorbs ein HistoryPoint gesetzt wird. Uns ist hier der State egal. In dem Navigate-EventHandler haben wir einfach die betreffenden UpdatePanels geupdated. Das funktionierte soweit ok. Beim Zurück-Surfen auf Seite X wurde sie kurz in dem “falschen” Zustand angezeigt, dann aber gleich die UpdatePanels neu geladen und vollständig angezeigt. Nicht schön, aber es funktionierte. Der Forward-Button funktionierte hier aber nicht.

Einfache Lösung

Ich suchte weiter, und, kurz bevor ich aufgeben wollte, fand ich eine erstaunlich einfache Möglichkeit, dem Browser mitzuteilen, dass er eine bestimmte Seite mit dem Back-Button nicht aus dem Cache holen soll, sondern einfach vollständig neu laden soll. Dies löste alle Probleme mit den UpdatePanels. Einfach

Response.Cache.SetNoStore();

in die Page_Load-Methode einfügen. Wer mehr zu den Klassen lesen möchte: HttpResponse.Cache Property und HttpCachePolicy Class. Diese Lösung habe ich nur nicht so schnell gefunden, weil sie von all den anderen Lösungen zu dem AJAX-Bach-Button-Problem verdrängt wird. Aber für die Problematik, wie sie sich uns darstellte, ist dies die beste Alternative, da wir ja wärend der AJAX-Calls keine History speichern wollen, was die meisten anderen Lösungen tun. Außerdem kamen wir so um die oft hässlichen Hashs in der URL herum. Auch der Forward-Button funktioniert verständlicherweise.

enjoyed the post?

Tags:

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

About Oliver

shades-of-orange.com code blog logo I build web applications using ASP.NET and have a passion for javascript. Enjoy MVC 4 and Orchard CMS, and I do TDD whenever I can. I like clean code. Love to spend time with my wife and our children. My profile on Stack Exchange, a network of free, community-driven Q&A sites

About Anton

shades-of-orange.com code blog logo I'm a software developer at teamaton. I code in C# and work with MVC, Orchard, SpecFlow, Coypu and NHibernate. I enjoy beach volleyball, board games and Coke.