In den letzten 5 Einträgen meines Blogs habe ich über verschiedene Möglichkeiten geschrieben Ajax in einer ASP.NET Webforms zu implementieren.
Angefangen mit dem manuellen Weg über das XmlHttpRequest Objekt ASP.NET Webforms Anwendungen und Ajax (Teil 1) ging es weiter zu Client Callbacks ASP.NET Webforms Anwendungen und Ajax (Teil 2) Client Callbacks, dem Updatepanel ASP.NET Webforms Anwendungen und Ajax (Teil 3) Das Updatepanel, dem ASP.NET Ajax Framework ASP.NET Webforms Anwendungen und Ajax (Teil 4) Scriptservices, Page Methods und das ASP.NET AJAX Framework sowie jQuery ASP.NET Webforms Anwendungen und Ajax (Teil 5) Scriptservices, Page Methods und jQuery.
Der Fokus meiner Beiträge lag darauf nicht nur einfach zu zeigen welche Möglichkeiten es gibt, sondern zusätzlich auch zu zeigen, welche Datenmengen über die Leitung gehen und ob bzw. welche Teile des ASP.NET Page Life Cycles durchlaufen werden.
Ich hoffe dass ich bei dem ein oder anderen Leser für manchen Aha Effekt sorgen konnte. Zumindest ging es mir persönlich bei der ersten detaillierten Auseinandersetzung mit dem Thema so. Schließlich ist man als ASP.NET Webforms Entwickler traditionell doch eher auf dem Server zu Hause und realisiert vorerst garnicht welchen Overhead Client Callbacks oder das Updatepanel mit sich bringen.
Mein persönliches Fazit ist, dass Updatepanel und Client Callbacks korrekt eingesetzt in einigen Fällen vielleicht berechtigte Alternativen sind, in den meisten Fällen jedoch zum Ajax Framework oder jQuery gegriffen werden sollte.
Meine zurzeit favorisierte Lösung ist - ähnlich wie bei vielen anderen sicherlich auch - der Einsatz von jQuery.
Da mein letztes Beispiel noch ein wenig aufgebläht war, möchte ich an dieser Stelle zwei kurze Tipps geben, die die Arbeit mit jQuery und Ajax ein wenig erleichtern.
Der erste Punkt beschäftigt sich mit der großen Redundanz zwischen den verschiedenen Ajax Aufrufen:
$("#StaticFileLink").click(function(e) {
e.preventDefault();
$.ajax({
type: "POST",
url: "Teil5.aspx/ReadStaticFile",
data: "{}",
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function(msg) {
$("#content").html(msg.d);
}
});
});
$("#HelloWorldLink").click(function(e) {
e.preventDefault();
$.ajax({
type: "POST",
url: "AjaxDemoService.asmx/HelloWorld",
data: "{}",
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function(msg) {
$("#content").html(msg.d);
}
});
});
$("#EchoLink").click(function(e) {
e.preventDefault();
var number = $("#EchoTextBox").val();
var jsonData = "{ 'number' : '" + number + "'}";
$.ajax({
type: "POST",
url: "AjaxDemoService.asmx/Echo",
data: jsonData,
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function(msg) {
$("#content").html(msg.d);
}
});
});
Bereits beim ersten Blick auf den Quellcode fällt auf, dass die Werte einiger Parameter statisch zu sein scheinen. So haben folgende Parameter stets einen fixen Wert:
- type
- contentType
- dataType
Außerdem ist zumindest in den ersten beiden Aufrufen auch der Eintrag für data gleich.
Ein Weg um diese Redundanz herum zu kommen wäre eine eigene Funktion, die nur die Variablen Parameter entgegen nimmt.
Standardwerte setzen
Eine andere Alternative besteht darin, Standardwerte für jQuery Ajax Aufrufe zu setzen. Dies sähe dann so aus:
<script type="text/javascript">
$(document).ready(function() {
$.ajaxSetup({
type: "POST",
data: "{}",
contentType: "application/json; charset=utf-8",
dataType: "json"
});
$("#StaticFileLink").click(function(e) {
e.preventDefault();
$.ajax({
url: "Teil6.aspx/ReadStaticFile",
success: function(msg) {
$("#content").html(msg.d);
}
});
});
$("#HelloWorldLink").click(function(e) {
e.preventDefault();
$.ajax({
url: "AjaxDemoService.asmx/HelloWorld",
success: function(msg) {
$("#content").html(msg.d);
}
});
});
$("#EchoLink").click(function(e) {
e.preventDefault();
var number = $("#EchoTextBox").val();
var jsonData = "{ 'number' : '" + number + "'}";
$.ajax({
url: "AjaxDemoService.asmx/Echo",
data: jsonData,
success: function(msg) {
$("#content").html(msg.d);
}
});
});
});
</script>
Neu hinzugekommen sind die Zeilen 2 - 8. Diese setzen Standardwerte für alle folgenden Ajax Aufrufe. Diese Variante kann einiges an Code sparen, ist allerdings mit Vorsicht zu genießen. Sollte nämlich zum Beispiel ein jQuery Plug-In auf der Seite genutzt werden, dass auch die $.ajax Funktion nutzt, könnte es zu Seiteneffekten kommen. Konkret wäre dies der Fall, wenn einer der per .ajaxSetup gesetzten Parameter nicht überschrieben, aber mit einem anderen Wert erwartet wäre. Typischerweise würde dies für den contentType oder oder dataType geschehen.
Serialisieren - einfach gemacht
Eine weitere Unschönheit des gezeigten Quellcodes besteht darin, dass die String Variante des in JSON notierten Objekts data von Hand zusammen gebaut wurde. Dies ist natürlich nicht sonderlich schick. Abhilfe schafft die Funktion stringify des Objekts JSON. Einige Browser wie Firefox ab Version 3.5 oder IE ab der Version 8 haben bereits ein eingebautes Objekt JSON. Für alle anderen gibt es unter http://www.json.org/js.html eine JavaScript Library zum Download, die entsprechenden Support nachrüstet, falls noch nicht vorhanden.
Konkret sähe dies dann wie folgt aus:
<script src="scripts/json2.js" type="text/javascript"></script>
[ … ]
$("#EchoLink").click(function(e) {
e.preventDefault();
var number = $("#EchoTextBox").val();
var jsonData = { 'number': number };
var jsonString = JSON.stringify(jsonData);
$.ajax({
url: "AjaxDemoService.asmx/Echo",
data: jsonString,
success: function(msg) {
$("#content").html(msg.d);
}
});
Wie man sieht, wird nun in Zeile 9 zuerst ein JavaScript Objekt jsonData in JSON Notation erzeugt. Dies wird anschließend über JSON.stringify in Zeile 10 in einen String konvertiert. Bei diesem konkreten Beispiel mag der Vorteil noch nicht auf der Hand liegen, spätestens bei komplexen Objekten lernt man die Funktion stringify jedoch schnell zu schätzen.
Bei der Recherche zu den Beiträgen dieser Serie bin ich übrigens auf einen sehr gut geschriebenen Eintrag von Roberto Bez gestolpert. Roberto stellt in seinem Blog Post die verschiedenen Varianten kompakt gegenüber. Die Lektüre des Artikels kann ich jedem Ajax interessierten Webforms Entwickler wärmstens empfehlen.
Weiter hat René Drescher-Hackel in einem Kommentar zu meinem letzen Beitrag, dass mit Ajax.NET Professional (AJAX.PRO) eine weitere effiziente Alternative zur Verfügung steht. Ich muss gestehen, dass mir die Existenz dieses Frameworks bis jetzt vollkommen entgangen ist. Gelobe allerdings Besserung und werde es mir gerne ansehen und mein Beispiel damit umsetzen.