Wie böse ist RAD?
Jeder der mich kennt, weiß, dass ich keine Freund von RAD-Controls (Rapid Application Developement) – besonders von Controls und Tools diverser Drittanbietern – bin.
Aber halte ich RAD deshalb generell böse?
Ralf Westphal schreib im aktuellen Beitrag seiner Kolumne “Sandbox” (in der dotnetpro 4/2010) sinngemäß und zusammengefasst: RAD-Tools für sich gesehen sind nicht böse, sondern die naive Herangehensweise, also zu glauben, dass RAD alle Probleme erledigt, ist böse, bzw. schlecht und die daraus resultierenden Probleme werfen ein schlechtes Licht auf RAD.
Ist das wirklich so?
Generell kann ich die Frage leider nicht komplett beantworten. Sondern nur aus meiner Sicht als Webentwickler, auf RAD-Tools und RAD-Controls für ASP.NET. Ich kann mich also nur auf ASP.NET beziehen und weis nicht wie es sich bei WinForms, WPF und SilverLight verhält.
So wie Ralf es beschreibt, würde ich generell erst mal “Ja” sagen, aber aus meiner Sicht kommen einige Fragen hinzu. Warum gibt es denn überhaupt die Möglichkeit, dass man sich bei naiver Herangehensweise seine komplette Anwendung mit RAD-Tools und RAD-Controls versauen kann? Warum schaffen es die Anbieter nicht, einfache, kleine und flexible Tools zu schaffen mit denen man nicht viel falsch machen kann? Warum müssen alle möglichen, erdenkbaren Funktionen von Anfang an in einem RAD-Tool, bzw. RAD-Control enthalten sein?
Schöne und positive Beispiele kommen von Microsoft selber: LINQ to SQL; die ASP.NET Controls GridView und Calendar sind absolut flexibel beliebig erweiterbar. Es ist also generell machbar.
Zu großer Umfang
Müssen RAD-Tools und drittanbieter-Controls so viele Funktionen anbieten, das der naive Nutzer alle Möglichkeiten ausnutzen will? Anbieter von RAD-Tools wollen die breite Masse zufrieden stellen und stellen deshalb die eierlegende Wollmilchsau zur Verfügung. Das muss aber nicht sein, ganz im Gegenteil. Ich persönlich nutze lieber die kleine Schlanke Komponente die ich selber erweitern kann und nicht das Universal-Tool von dem ich 80% nicht benötige, aber mit schleifen muss.
Unförmiger HTML Code
Wer meinen UG-Vortrag im Herbst (beim .NET-Stammtisch Konstanz-Kreuzlingen) gesehen hat, konnte miterleben wie sich die verschiedenen Hersteller bei der Menge an HTML-Code, JavaScripts und HTML-Verschachtelungen überboten haben. (Ich bin gerne bereit diesen Vortrag auch in einer anderen UGs zu halten. Machen Sie sich dabei auf was gefasst *fg*)
Ein namhafter Hersteller von RAD-Controls zwingt die Browser in die Knie, wenn man mehr als 10 abhängige Comboboxen nutzt, die unter anderem Grids beinhalten. Eine Combobox dieses Anbieters benötigt für 10 Listeneinträge übrigens mehrere ineinander verschachtelte HTML-Tabellen und mehr als 30 Zeilen HTML-Code. Nutzt man zusätzlich noch die Möglichkeit, beim Aufklappen der Combobox ein Grid anzuzeigen, erhöht sich die Menge des benötigten HTML-Codes um die benötigte Menge des Grids, welches auch nicht gerade sparsam mit verschachtelten HTML-Tabellen umgeht. Hinzu kommen Unmengen von JavaScripts, die direkt auf der Seite ausgegeben werden. Die kleine Combobox entpuppt sich bei genauerer Betrachtung als ein riesiges, unperformates und überladenes Control.
Ein weiterer Hersteller hatte es übrigens nicht geschafft, trotz enormer Mengen an unsauberen Code und JavaScripts, die Combobox in allen Browsern zu funktionieren: Im Opera war lediglich eine leere Standard-Combobox zu sehen.
Zu unflexibel und schlecht erweiterbar
Warum schaffen es die meisten Hersteller von RAD-Tools und drittanbieter-Controls nicht, flexible und erweiterbare Tools und Controls zu erstellen?
In einer Kalender-Komponente eines weiteren namhaften Herstellers, benötigte ich zwei Wochen, um ein Doppelklick-Event auf einen Kalendertag abzufangen und einen eigenen Termindialog anzubinden.
- Warum ich nicht den vorhandenen Dialog genutzt habe?
Dieser Passte nicht zu der Art von Terminen war nur schwer erweiterbar und passte nicht in das Layout.
- Warum ich nicht die Komponente eines anderen Herstellers genommen habe?
Alle anderen waren aufgrund von unsauberen HTML-Code einfach zu unperformant beim Aufbau der Seite, zudem schaffte es das herstellereigene JavaScript nicht mal mehr die per Callback geholten Termine in diesen unmöglichen Code zu setzen.
Grund hier war eine nicht dokumentierte, clientseitige JavaScript API und das tagelange JavaScript-Debugging in unschönem Code.
Fazit
Es ist nicht nur alleine die Naivität der, Nutzer sondern auch die Art wie die Hersteller die Controls produzieren und vermarkten. Auf den Demoseiten der Hersteller sieht alles toll und bunt aus, alles funktioniert einwandfrei, aber dort habe ich auch nie mehr als zehn abhängige Grid-Comboboxen gesehen ;-)
Man RAD-Controls ist man unheimlich schnell bei der Entwicklung von schönen, bunten und benutzerfreundlichen Oberflächen.
Mit RAD-Controls stößt man aber auch unheimlich schnell auf Probleme, wenn man spezielle Anforderungen hat und wenn man Anpassungen und Erweiterungen an den Controls vornehmen möchte. RAD-Controls werden als schnell einsetzbare Tools präsenteiert, aber unter den schönen bunten Oberfläche erweisen sich die meisten als unflexibel, schlecht dokumentiert und unperformant.
Klingt jetzt wahnsinnig abwertend, gell?
Aber ich möchte RAD-Controls nicht generell schlecht machen. Wenn man keine sehr speziellen Anforderungen an z. B: Grid und Kalender-Controls hat, kann und sollte man diese auch nutzen. Der Entwicklungsaufwand um selber eine entsprechendes Control zu schreiben ist einfach zu hoch.
Nur warum sollte man eine TextBox, eine ComboBox, eine CheckBox, etc. von einem Drittanbieter verwenden? Wegen dem schönen Design? Wohl kaum, denn dafür gibt es CSS.
Wegen einer speziellen Funktion mehr? Eine Funktion ist schnell selber geschrieben. Oder man benutzt vorhandene JavaScript-Frameworks, wie z. B. jQuery, um Controls zu erweitern ohne den HTML-Code aufzublähen und die Browser in die Knie zu zwingen.
Im Gegenteil halte ich RAD für absolut Sinnvoll und sollte auf alle Fälle in Betracht gezogen werden, wenn es darum geht den Aufwand klein zu halten. Allerdings hat Ralf absolut recht, wenn man die meisten, heute auf dem Markt befindlichen RAD-Tools anschaut, sollte, bzw. darf man nicht naiv daherkommen und einfach so alle möglichen Tools einsetzen und nutzen, sondern sollte sich penibel mit den Tools auseinandersetzen, abwägen und schauen wie erweiterbar und flexibel die Controls und Tools wirklich sind.
Zu guter Letzt:
Ich kann es einfach nicht lassen und muss hier mal ein anonymisiertes Beispiel posten.
Es soll ein schöner, bunter, formatierter Button angezeigt werden:
<table cellpadding="0" cellspacing="0" style="height: 57px;">
<tr>
<td>
<table cellspacing="0" cellpadding="0" id="ctl00_phContent_BackgroundImageTextGroupBox_Button1" border="0" style="height:30px;width:90px;border-collapse:collapse;border-collapse:separate;">
<tr>
<td id="ctl00_phContent_BackgroundImageTextGroupBox_Button1_B" align="center" style="color:White;background-image:url(Images/Wine/normal.jpg);cursor:pointer;padding-bottom:2px;">
<div id="ctl00_phContent_BackgroundImageTextGroupBox_Button1_CD" class="dxb">
<span>Submit</span>
</div>
</td>
<td style="width:0%;">
<input value="" onfocus="ButtonGotFocus('ctl00_phContent_BackgroundImageTextGroupBox_Button1')" name="ctl00$phContent$BackgroundImageTextGroupBox$Button1" type="submit" style="background-color:Transparent;border-width:0px;height:0px;width:0px;padding:0px;" />
</td>
</tr>
</table>
<script id="dxss_202605327" type="text/javascript">
<!--
addHoverItems('ctl00_phContent_BackgroundImageTextGroupBox_Button1',[[[''],['padding-bottom:2px;color:#FAD9E0;background-image:url(Images/Wine/hover.jpg);'],['B'],['','TC'],[['']],['Img']]]);
addPressedItems('ctl00_phContent_BackgroundImageTextGroupBox_Button1',[[[''],['padding-bottom:2px;color:#DCB7C8;background-image:url(Images/Wine/pressed.jpg);'],['B'],['','TC'],[['']],['Img']]]);
var o = new ClientButton('ctl00_phContent_BackgroundImageTextGroupBox_Button1');
window['ctl00_phContent_BackgroundImageTextGroupBox_Button1'] = o;
o.uniqueID = 'ctl00$phContent$BackgroundImageTextGroupBox$Button1';
addSelectedItems('ctl00_phContent_BackgroundImageTextGroupBox_Button1',[[['bf'],[''],['CD']]]);
o.InlineInitialize();
//-->
</script>
</td>
</tr>
</table>
Die “alternative” mit normalem HTML würde so aussehen:
<input type="submit" value="Submit" class="beautifulButton" id="submitButton" runat="server" />
Formatiert mit CSS und ggf. erweitert per jQuery und man hat ein besseres Ergebnis, da der HTML-Code schlanker ist und die Browser weniger zeit für die Verarbeitung benötigen.
