Streitgespräch

Komponentenorientiert vs. nicht komponentenorientiert
Kommentare

Herr Haimberger, warum wurde Prototype bei der Entwicklung der AJAX-Funktionalität von Rails verwendet? Haimberger: Prototype ist eines der ersten verfügbaren JavaScript-Frameworks mit eingebauter

Herr Haimberger, warum wurde Prototype bei der Entwicklung der AJAX-Funktionalität von Rails verwendet? Haimberger: Prototype ist eines der ersten verfügbaren JavaScript-Frameworks mit eingebauter AJAX-Unterstützung gewesen und ist auch heute noch eines der am weitesten verbreiteten. Prototype hat einen sehr einfachen und leicht verständlichen Zugang für die AJAX-Unterstützung gewählt und ist außerdem sehr gut dokumentiert. Ein AJAX-Aufruf mit Prototype funktioniert so: Es wird action bei dem Controller controller aufgerufen und Wert als Parameter in der Variablen Param übergeben.

new Ajax.Request("/controller/action ", { 
  onSuccess : function(resp) { 
    alert("Die Antwort vom Server war: " + resp.responseText); 
  }, 
  onFailure : function(resp) { 
    alert("Es ist ein Fehler aufgetretten."); 
  }, 
  parameters : "Param=Wert " 
});

Dieser einfache Aufruf ist auch für die Integration in das Framework außerordentlich wichtig. Wie Abbildung 2 zeigt, wird bei einem AJAX Request nur ein gewisser Teil gerendert und an den Client geschickt, wobei bei einem normalen Request dieser Teil noch mit einem Layout versehen wird.

Abb. 2: Verschiedene Requests

Herr Fastl, welches Framework verwendet Apache MyFaces für die AJAX-Unterstützung? Fastl:MyFaces, wie die meisten Java-basierten Web-Frameworks, verwendet Dojo für die integrierte AJAX-Unterstützung. Auch mit Dojo ist die Absetzung eines AJAX-Aufrufs denkbar einfach (Listing 4).

Listing 4
dojo.io.bind({
  url: requestUri,  //Zieladdresse des Requests
  method: "post",   //Request-Method
  useCache: false,  //Client-Side-caching an/aus
  content: content, //assoziatives Array mit Request-Parameter
  handle: this.handleCallback,//Callback-Funktion 
                              //die den Response entgegennimmt
  mimetype: "text/xml", //wir verwenden xml für den Response
  transport: "XMLHTTPTransport", //ein XML-HTTP-Request
  formNode: this.form  //alle inputs dieses Forms werden submitted
});

handleCallback = function(type, data, evt)
  {
    if(type == "load")
    {
....// response verarbeiten
    }
    else
    {
      alert("an Error occured during the ajax-request " + data.message);
    }
  }

Ein Aufruf der Methode dojo.io.bind genügt, um einen vollständigen AJAX-Request durchzuführen. Anfangs wurde zwar ebenfalls Prototype eingesetzt, doch davon sind wir relativ schnell abgekommen. Das hat damit zu tun, dass das Namespacing von Prototype – nennen wir das Kind beim Namen – „unter’m Hund“ ist. Prototype definiert solche Dinge wie die JavaScript-Klasse Event – wenn ein anderes Framework auch auf diesen Gedanken kommt, wird nichts mehr funktionieren. Das ist ähnlich wie beim Verhalten im Verkehr: ein Verkehrsteilnehmer darf noch einen fahrlässigen Fehler machen, wenn ein Zweiter ebenfalls unvorsichtig ist, wird die Angelegenheit schon schlimmer. Von der Verwendung her ist Dojo genauso einfach.

Haimberger:…dafür ist die Dokumentation von Dojo „unter’m Hund“!

Das ist allerdings richtig – aber deswegen werden wir doch nicht gleich ausfällig werden, meine Herren. Auf zum nächsten Thema: der Einfachheit der Einbindung von AJAX in die eigene Webanwendung.

Einbindung von AJAX

Herr Haimberger, Rails ist für seine Einfachheit bekannt, die erste Testanwendung ist in fünfzehn Minuten erstellt. Fastl: Das geht mit JSF auch.

O.k., o.k., lassen Sie mich bitte trotzdem die Frage an Herrn Haimberger stellen. Wie einfach ist denn die Einbindung von AJAX in die eigene Webanwendung mit Rails? Haimberger: Außerordentlich einfach. Ein Helper-Element sorgt für die Einbindung der notwendigen JavaScript-Dateien im Kopf der HTML-Datei, und dann können sehr viele vordefinierte Helper-Elemente verwendet werden.  Zum Beispiel lässt sich mit einem Helper-Element definieren, dass gewisse Seitenbereiche bei einem Klick auf ein Element vom Server neu geladen werden. Das war’s auch schon.

Herr Fastl, wie funktioniert das in JSF? Fastl:Noch einfacher. Eine Einbindung in den Kopf ist nicht vonnöten, den Rest erledigen die verwendeten Komponenten selbst. Die Ressourcen werden von Filtern beziehungsweise PhaseListenern (ein spezieller JSF-Begriff) automatisch geladen. Die Einbindung funktioniert damit wirklich sehr schön und vollständig transparent für den Benutzer. Die Rolle der Helper in Rails übernehmen hier die Komponenten, die aber nicht nur das Rendern in die Ausgabe, sondern auch das Auslesen der Benutzereingaben übernehmen. Komponenten in JSF sind eine Black-Box, die die Verantwortung für die gekapselten Daten übernehmen, Helpers sind dagegen nicht viel mehr als mit ein wenig Funktionalität angereicherte HTML-Tags.

Haimberger:Die aber dafür wirklich einfach funktionieren, im Gegensatz zu JSF-Komponenten. Mit dem gar nicht so einfachen Lebenslauf einer JSF-Anfrage gekoppelt, ist die Verwendung von JSF-Komponenten nicht immer wirklich durchsichtig.

Komponente vs. Helper

Fastl: Lassen Sie mich einen Vergleich bringen, um die Sache deutlicher zu machen: Rails-Helper sind nicht anders als prozedurales Programmieren, eine richtige Objektorientierung lässt sich erst durch Komponenten erzielen, die die Daten, für die sie zuständig sind, auch wirklich selbst verwalten können. Ein Rails-Helper kann mit den Daten, die durch ihn durchgeschleust werden, nicht wirklich viel anfangen, eine JSF-Komponente hat die volle Verfügungsgewalt über die zugehörigen Datenstrukturen.

Haimberger:Wofür soll ein Helper seine zugehörigen Datenstrukturen verändern? Die Objektorientierung wird schließlich dadurch erzielt, dass die zugehörigen Daten in den „Models“ der Rails-Anwendung gekapselt sind. Da soll der Entwickler dann auch die Verwaltung der Daten vornehmen, dann kann er leicht andere Benutzer erreichen, nicht nur Web-Clients.

Fastl: Also so sehe ich das nicht. Es existiert auf jeden Fall Funktionalität, die in den Komponenten gekapselt sein soll und dort Sinn macht. Zum Beispiel ist es mit JSF ganz einfach, ein gültiges Modell hinter der Komponentenschicht zu erhalten; nur ein vollständig konvertierter und validierter Komponentenbaum wird ins Model übernommen. Viel wichtiger ist aber ganz einfach, dass die Verbindung zwischen Helper und zu veränderndem Model-Attribut explizit gemacht werden muss. Gerade bei der Verwendung von AJAX ist das eine fehlerträchtige Vorgangsweise. In JSF weiß die Komponente implizit über das zugehörige Model Bescheid. Für kleine Webanwendungen mag die erste Vorgangsweise noch funktionieren, für riesige Webanwendungen wird man aber unweigerlich Schiffbruch erleiden.

Haimberger: Es sei denn, das Projekt hat eine klar definierte und wohlüberlegte Richtlinie über Namenskonventionen, was Rails ohnehin schon vorgibt, durch das ins Framework integrierte Prinzip von „Convention over Configuration“.

Fastl:Es ist aber immer einfacher, wenn sich das Team nicht auf die Einhaltung von Konventionen verlassen muss, gerade bei großen, diversifizierten und räumlich getrennten Teams.

Haimberger: Die „Helper“ von Rails sind aber zweifellos einfacher zu verwenden und zu erstellen als die JSF-Komponenten. Ich bezweifle, dass die Einhaltung von Konventionen in Rails im Vergleich so viel schwieriger ist als die Verwendung von Komponenten gegenüber Helpern. Grundsätzlich sollte bei entsprechender Dokumentation die Einhaltung von Konventionen für die Projektmitglieder überhaupt kein Problem sein.

Fastl: Helper mögen vielleicht einfacher sein, die Komponenten von JSF erhöhen aber den Wiederverwendbarkeitsgrad von Webanwendungen. Module lassen sich damit besonders einfach erstellen und in anderen Webanwendungen neu einsetzen! In JSF kann sich ein Entwickler speziell auf die Komponentenentwicklung konzentrieren, dann ist die Komplexität kein Thema mehr, bei Rails muss jeder Seitenentwickler auch Ahnung vom AJAX-Ablauf haben.

Versuch eines Resümees

Die Wogen gehen hoch, und wie so oft bestätigt sich die Annahme, dass die Fronten zwischen den Anhängern von Webframeworks verhärtet sind. Je nachdem, wie die Projektanforderungen aussehen, kann die Bilanz bei der Verwendung der beiden Frame­works aber unterschiedlich ausfallen. Ein perfektes Framework für alle Anwendungen gibt es nicht. Für Rails und ein nicht komponentenorientiertes Framework spricht die niedrige Komplexität, der Einstieg ist einfach, es lassen sich schnell erste Erfolge mit AJAX erzielen. Ein komponentenorientiertes Framework wie JSF hilft aber bei größeren Projekten und Projekten mit Teams bei der einheitlichen Herangehensweise an die Lösung des Problems, AJAX vernünftig an den Client zu bringen. Die Einbindung von AJAX in Webanwendungen ist generell nicht einfach, Web-Frame­works tun aber alles dafür, diese Einbindung zu erleichtern. Sowohl Rails als auch MyFaces bieten hier eine volle Unterstützung an, der Level der Unterstützung, den komponentenorientierte Frameworks wie JSF bieten können, ist aber naturgemäß etwas größer, da hier sowohl das Rendering als auch der Postback von der Komponente selbst behandelt wird und mehr Funktionalität für den Benutzer weggekapselt bleibt. Dadurch, dass Rails eines der ersten Frameworks mit Unterstützung für AJAX war, ist aber ein gewisser Reifegrad zu spüren und damit ein Vorsprung, den MyFaces erst aufholen muss.

Ganz gleich, für welches Paradigma und welches Framework Sie sich entscheiden: wir wünschen Ihnen viel Spaß beim Einsatz von AJAX! Und wir hoffen natürlich, dass Sie Ihre Entscheidung entweder für Rails oder für MyFaces treffen werden.

Martin Marinschek, Ernst Fastl und Martin Haimberger arbeiten für das MyFaces und Rails Consulting- und Schulungsunternehmen IRIAN.at. Gemeinsam verfassen sie Bücher und Artikel (siehe z.B. Marinschek/Radinger: „Ruby on Rails. Einstieg in die effiziente Web-Entwicklung“, dpunkt, 2006. Marinschek/Schnabl: „JSF@Work. JSF und Apache MyFaces richtig einsetzen“, dpunkt, 2006.) zu diesen Frameworks. Martin Marinschek ist Committer und PMC-Member von Apache MyFaces.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -