Microsofts AJAX-Lösung zeigt Schwächen

Microsofts AJAX-Lösung (früher: "Altas") ist Ende Januar erschienen. In diesem Beitrag möchte ich einige Schwächen aufzeigen, die sich inzwischen im Praxiseinsatz gezeigt haben.

Differenzieren muss man dabei zwischen
a) dem Kernprodukt ASP.NET AJAX, das aus den Teilen Microsoft AJAX Library und den ASP.NET AJAX-Erweiterungen besteht sowie
b) dem "Community"-Projekt AJAX Control Toolkit

ASP.NET AJAX: Microsoft AJAX Library und die ASP.NET AJAX-Erweiterungen

ASP.NET AJAX besteht wieder aus zwei Teilen:

1. Die Microsoft AJAX Library ist der browserunabhängige, clientseitige, in Javascript geschriebene Teil von Microsofts AJAX-Lösung.
2. Die ASP.NET-AJAX-Erweiterungen sind eine Sammlung von ASP.NET-Serversteuerelementen, HTTP-Handlern und HTTP-Modulen für den IIS, die ASP.NET um AJAX-Funktionen ergänzen.

Die beiden Kernfunktion (Partielle Seitenerzeugung und Web-RPC) sind mächtig und lassen sich einfach bedienen. Negativ fallen hier nur die grauen Kästen auf, die das UpdatePanel-Steuerelement um jedes zu aktualisierende Seitenfragment wirft. Die Kästen lassen sich nicht ausblenden und zerstören somit die WYSIWYG-Ansicht im Visual Web Developer.

Derzeit auch ein Problem gibt es mit den ASP.NET-Eingabevalidatoren. Diese bereits mit ASP.NET 2.0 im November 2005 ausgelieferten Komponenten funktionieren nicht mehr richtig auf einer Seite mit UpdatePanel. Den notwendigen Patch hat Microsoft leider nicht in ASP.NET AJAX 1.0 integriert. Während die Entwicklergemeinde auf die offizielle Freigabe des Patches warten muss, gibt es nur eine Übergangslösung, versteckt im Blog eines Mitglied des Entwicklungsteams.

AJAX Control Toolkit

Das optionale AJAX Control Toolkit ist eine Sammlung von DHTML-Widgets (wie Eingabeprüfung, Navigationselementen und grafischen Spielereien wie Schatten und Animationen). Das Control Toolkit ist kein klassisches Microsoft-Produkt, sondern Microsoft bezeichnet es als "Gemeinsames Projekt von Microsoft und der .NET Community", das im Rahmen des Projektportals Codeplex zur Verfügung steht. Jedermann hat die Möglichkeit, sich für eine Mitarbeit bei dem Projekt zu bewerben.

Während ich schon seit Monaten intensiv mit AJAX Library und den ASP.NET AJAX-Erweiterungen (also auch schon mit den Beta-Versionen) arbeite, habe ich bislang das AJAX Control Toolkit nur partiell betrachtet. Aus meiner Sicht geht es da zu sehr um "oberflächliche" Spielereien, an denen sich Webdesigner erfreuen werden, aber nicht "richtige" Programmierer. Die "richtige" Programmierung läuft doch im Backend auf dem Server... :-)

Im Zuge eines Projekts und meiner AJAX-Webcasts für MSDN musste ich mich jetzt aber intensiver mit dem AJAX Control Toolkit beschäftigen. Die von Microsoft mitgelieferten und im WWW bereitgestellten Beispiele funktionieren. Aber alle diese Beispiele verwenden nur ein, höchstens zwei AJAX-Steuerelemente auf einer Seite. Was passiert, wenn man mehrere Steuerelemente zusammen nutzen und ggf. auch noch verschachteln möchte (z.B. ein NumericUpDown in einem Accordion einbetten), zeigen die folgenden Screenshots. Besonders zu beachten ist, dass im Firefox (jeweils rechts) weniger Darstellungsfehler auftreten als im Internet Explorer 7.0 (jeweils links). Ein schwacher Trost: Zumindest sind die Darstellungsfehler reproduzierbar und nicht zufällig.

Leider ist auch die Dokumentation zu dem Control Toolkit sehr spärlich: Sie existiert nur in kurzen Anmerkungen in den einzelnen Beispielseiten. Ansonsten bleibt nur der Blick in den Quellcode.

Wenn Sie es trotz meiner Erfahrungen mit dem AJAX Control Toolkit versuchen wollen, möchte ich Sie noch vor zwei Dingen warnen:

1. Erwarten Sie nicht, dass es ein setup.exe gibt, das Visual Studio passend konfiguriert. Die Projektvorlagen müssen durch ein VSI-Paket installiert werden. Danach muss man die neuen Steuerelemente manuell in die Toolbox aufnehmen.
2. Erwarten Sie von den Steuerelementen aus dem AJAX Control Toolkit nicht den gleichen Bedienungskomfort wie bei den "normalen" ASP.NET-Serversteuerelementen. Viele der AJAX-Steuerelemente haben keinen oder nur einen rudimentären Designer. Sie erscheinen nur als grauer Kasten auf dem Bildschirm. Gerade bei Container-Elementen ist das lästig und führt dazu, dass man viele Seiten in der Markup-Ansicht entwickeln muss.

ASP.NET AJAX Futures

Unter dem Titel ASP.NET AJAX Futures liefert Microsoft eine Vorabversion der Teile von ASP.NET AJAX, die noch nicht das endgültige Produktstadium erreicht haben und erst Ende 2007 zusammen mit .NET 3.5 erscheinen sollen.

Auch hier ist Frustration angesagt: Nach dem Hinzufügen der ASP.NET AJAX Futures (Microsoft.Web.Preview.dll) zu einem ASP.NET AJAX-Webprojekt funktionierten plötzlich die CascadingDropDownExtender aus dem AJAX Control Toolkit nicht mehr, sondern lieferten nur noch nichtssagende Fehlercodes wie "12030". Erst die Betrachtung des HTTP-Datenstroms mit einem Netzwerkmonitor offenbarte, dass in der mit den ASP.NET AJAX Futures gelieferten Konfigurationsdatei als Standardeinstellung für die Maximalgröße eines JSON-Aufrufs "500 Bytes" hinterlegt war: . Eine völlig unrealistisch kleine Zahl.

Von den ASP.NET AJAX Futures erwartet jedoch niemand, dass sie jetzt schon fehlerfrei seien. Aber es gibt noch keine Dokumentation, sondern nur ein paar Beispiele. Wer damit arbeiten will, sollte also viel, viel Zeit übrig haben.

Fazit

Das Kernelement der Lösung, die ASP.NET AJAX Extensions sind im Wesentlichen brauchbar – Schwächen gibt es hier nur im Entwicklerkomfort. Beim näheren Betrachten des AJAX Control Toolkits zeigen sich grausame Fehler – interessanterweise mehr beim Aufruf mit Internet Explorer als im Firefox.

Immer mehr bekomme ich das Gefühl, Microsoft hätte den Erscheinungstermin seiner AJAX-Lösungen doch beim ursprünglichen Datum (Ende 2007) belassen sollen und das ganze Produkt aus einer Hand und an einem Stück (zusammen mit dem für Ende 2007 angekündigten neuen Webdesigner Sapphire) liefern sollen. Die Vorverlegung erweist sich in einigen Punkten für den Entwickler eher als Bürde denn als ein Segen.

Und: Wenn Fehler und schlechte Dokumentation die Folge der zunehmenden Quellcodeoffenheit bei Microsoft sind, dann sollte Microsoft lieber den Quellcode wieder für sich behalten und die Produkte zuverlässiger entwickeln. ()