JQuery oder AjaxControlToolkit: Eine klare Sache

Um moderne Benutzeroberflächen bereit zu stellen braucht es heute mehr als nur die Standard-Controls von ASP.NET. Asynchrone (Teil-)Postbacks, dynamisches Laden von Daten, komplexe modale Popups und vor allem auch Client-Seite Verarbeitung von Logik und Darstellungsänderungen sind heute längst etabliert. Im Rahmen eines grossen Entwicklungsprojektes haben wir uns deshalb dafür entschieden, die OpenSource Bibliothek JQuery sowie das von Microsoft und der Microsoft ASP.NET Community getrieben AjaxControlToolkit einzusetzen.

JQuery haben wir für Manipulationen des HTML-DOMs auf dem Client vorgesehen, die Controls und Extender des AjaxControlToolkits für die server-seitige Verwendung in WebControls. Die Wahl fiel auf das AjaxControlToolkit, weil es für ASP.NET Entwickler enorm einfach ist, die Komponenten und Extender in eigenen Controls einzusetzen: Diese können genau gleich wie „normale“ Server-Controls im Code oder im Markup eingesetzt werden und stellen sofort Ihre Funktionalität zur Verfügung. JQuery wurde am Anfang sehr spärlich eingesetzt, da dies für viele Entwickler eine ziemlich neue „Technologie“ war.

Interessant war dann allerdings die Entwicklung innerhalb des Projektes: Mit dem AjaxControlToolkit sind wir sehr schnell einmal auf offensichtliche Limiten und z.T. auch Fehler im JavaScript-Code gestossen. Was soll man aber nun tun mit einem Produkt, welches über grosse und unübersichtliche JavaScript-Bibliotheken verfügt und deren Source man nicht einfach beliebig abändern sollte um Update-Fähig zu bleiben? In der folgenden Liste möchte ich kurz zusammenfassen, auf welche Probleme wir gestossen sind:

-          Z-Index Probleme: Aufgetreten beim Kalender und beim ModulDialogPopupExtender: Gewisse Elemente der Seite wurde nicht dem Ajax-Control untergeordnet, als Entwickler hat man kaum/keinen Einfluss auf die Darstellung der Controls und wir haben maximal unelegante Workarounds im Internet gefunden.

-          Page Output Caching wird nicht unterstützt: Microsoft unterstützt gemäss unseren Recherchen im Web kein Page Output Caching für Seiten mit Controls oder Extendern des AjaxControlToolkits. Für dies kann Dank des ToolkitScriptManagers ein Workaround gemacht werden (laden der Scripts von einem anderen URL/HttpHandler).

-          Kaum Einfluss auf Scripts zur Laufzeit: Die Controls und Extender des AjaxControlToolkits werden server-seitig vorkonfiguriert, die JavaScripts, welche auf dem Client zum Einsatz kommen können aber nur sehr mühsam in Ihrer Funktionalität angepasst werden.

-          Grosse, unübersichtliche und z.T. offensichtlich fehlerhafte JavaScripts. Das AjaxControlToolkit ladet im Vergleich zur effektiven Funktionalität der einzelnen Controls und Extender sehr umfangreiche JavaScript Bibliotheken. Schlimmer noch: Diese werden in verschienen Request einzeln geladen, wenn man nicht durch Verwendung des ToolkitScriptManager und eigenem Code einen ScriptCombiner bereitstellt.

-          „Schwere“ Seiten: Der JavaScript Code, welcher die Funktionalität der einzelnen Controls ermöglicht wird direkt in die Seite geschrieben. Dies erhöht die Grösse der einzelnen Seiten beträchtlich und verschlechtert so die Ladezeiten.

Alles in allem haben wir uns bei der Verwendung der AjaxControlToolkit Controls und Extendern je länger je schwerer getan. Es war wie sehr oft mit neuen Microsoft Komponenten: Am Anfang geht es rasend schnell bis man etwas zusammen hat, aber der Teufel liegt im Detail und dem verdanken wir im Nachhinein grossen Zusatzaufwand (Fehlersuche, ScriptCombiner, PageOutputCaching Workaround) und z.T. unlösbare Probleme – welche wir schlussendlich mit JQuery fast im Handumdrehen lösen konnten.

Damit sei das Fazit meines Beitrags auch schon vorneweg genommen. JQuery kam im Laufe des Projekts immer mehr zum Einsatz: Am Anfang waren es kleine Scripts, welche etwa eine CSS-Klasse dynamisch setzten, später kamen mehr und mehr Plugins und vor allem die Verwendung der JQuery UI Bibliothek hinzu. Mehr und mehr AjaxControlToolkit Controls und Extender mussten weisen, denn nach anfänglichen Schwierigkeiten hat sie die Arbeit mit JQuery als äussert einfach und enorm produktiv herausgestellt. Dies sind die Vorteile die ich im Einsatz von JQuery sehe:

-          Schlanke (Grund-)Bibliothek mit mächtigem Funktionsumfang und kaum Fehlern

-          Unzähligen Plug-Ins und AddOns.

-          Gute Dokumentation und viele Beispiele

-          Scripts lassen sich in separate JavaScript-Dateien auslagern, komfortable Selektoren und vor allem Bindings erlauben das „Andocken“ an allen möglichen DOM-Elementen zur Laufzeit und auch nach asynchronen Postbacks.

-          Volle AJAX-Requests Unterstützung mit JSON etc.

-          Page Output Caching wird implizit unterstützt

Mit JQuery lassen sich auch komplexeste Funktionen in sehr kurzer Zeit ohne viel JavaScript-Code realisieren und Dank den Plug-Ins, z.B. der JQuery UI Bibliothek lassen sich auch komplexere „Controls“ wie ein Akkordion oder modale Popups einfachst implementieren. Der wohl grösste Vorteil von JQuery liegt aber nicht nur darin, dass die fast vollständige Kontrolle über die client-seitig ausgeführten Scripts hat, sondern dass man die Seite nicht mit zusätzlichem Overhead belasten muss und „sauberes“ HTML schreiben kann: Werden Css-Klassen und z.B. DIV-IDs richtig gesetzt kann Dank den JQuery Selektoren einfachst mit demselben Skript in einer ausgelagerten Datei Funktionalität für eine seiten-übergreifend bereitgestellt werden.

Da wir verschiedene Plub-Ins verwenden haben wir auch einige JavaScript-Dateien in den Client hochzuladen. Hierfür verwenden wir einen ScriptCombiner (und –Komprimierer), so dass immer nur eine Datei heruntergeladen und client-seitig gecached wird.

Alles in allem empfehle ich deshalb aufgrund der gemachten Erfahrungen im letzten halben Jahr, JQuery als erste Wahl auch bei der Entwicklung von SharePoint Lösungen in Betracht zu ziehen. Von der Verwendung des AjaxControlToolkits hingegen rate ich aufgrund der oben genannten Gründe eher ab.

Dieser Blog-Eintrag wurde noch nicht kommentiert.