Einer der Aspekte, die bei meiner Entscheidung für ein neues Webframework eine große Rolle spielten, war die Integration von Ajax. Fast jedes aktuelle Framework bietet eine Unterstützung von Ajax, doch unterscheiden sie sich in Handhabung und Möglichkeit.

Die komponentenorientierte Arbeitsweise von Wicket führt dazu, dass eine Wicket-Seite (die Entsprechung einer Webseite), aus einem Komponentenbaum besteht, bei der jede Komponente für ihre Darstellung verantwortlich ist. Daher ist es besonders einfach, den Teil zu identifizieren, der durch die jeweilige Komponente dargestellt wird. Diesen Umstand macht sich Wicket zu nutze, um im Gegensatz zu anderen Frameworks, beliebig viele Bereiche der Webseite aktualisieren zu können.

Im folgenden Beispiel soll das veranschaulicht werden:

package de.wicketpraxis.web.blog.pages.migration.ajax;

import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.Model;

public class AjaxMultiUpdatePage extends WebPage
{
  public AjaxMultiUpdatePage()
  {
    final FeedbackPanel feedback=new FeedbackPanel("feedback");
    feedback.setOutputMarkupId(true);
    add(feedback);
    
    // die geschweiften Klammern haben keine Funktion
    // sie sollen nur den Komponentenbaum veranschaulichen
    WebMarkupContainer block = getBlock(feedback,1);
    {
      WebMarkupContainer block2 = getBlock(feedback,2);
      {
        WebMarkupContainer block3 = getBlock(feedback,3);
        block2.add(block3);
      }
      block.add(block2);
    }
    add(block);
  }

  private WebMarkupContainer getBlock(final FeedbackPanel feedback, int start)
  {
    final WebMarkupContainer block = new WebMarkupContainer("ajaxUpdate");
    block.setOutputMarkupId(true);
    
    Model<Integer> model = Model.of(start);
    final Label label = new Label("count",model);
    label.setOutputMarkupId(true);
    block.add(label);
    
    block.add(new AjaxFallbackLink<Integer>("link",model)
    {
      @Override
      public void onClick(AjaxRequestTarget target)
      {
        setModelObject(getModelObject()+1);
        info("Aktualisiere "+getPath());
        if (target!=null)
        {
          target.addComponent(feedback);
          target.addComponent(block);
          
          // ist nicht nötig
          target.addComponent(label);
        }
      }
    });
    
    return block;
  }
}

Wir fügen der Seite ein FeedbackPanel hinzu. Für jede Komponente, die per Ajax aktualisiert werden soll, muss die setOutputMarkupId(true) aufgerufen werden. Dass veranlasst Wicket, in dem Html-Tag dieser Komponente das id-Attribut zu setzen. Das ist notwendig, damit Wicket diesen Tag dann durch neuen Inhalt ersetzen kann.

Als weiteres erzeugen wir einen WebMarkupContainer. Dieses Element dient uns als Rahmen, um die Aktualisierung des ganzen Blocks anstoßen zu können. Als Kindelemente definieren wir zusätzlich ein Label, das den Inhalt eines Modells darstellt, dass wir gleichzeitig in einem AjaxFallbackLink benutzen. Klickt der Nutzer auf den Link, wird der Wert im Modell erhöht und der Block sowie das FeedbackPanel in die Liste der zu aktualisierenden Komponenten aufgenommen. Auch das Label wurde zu dieser Liste hinzugefügt. Allerdings kommt hier bereits eine Optimierung zum Vorschein, die Wicket vornehmen kann, da der Komponentenbaum bekannt ist: Wicket ersetzt den ganzen Block und weiß, dass damit auch das Label aktualisiert wurde, weshalb es nicht gesondert ersetzt werden muss.

Innerhalb eines Blockes fügen wir einen weiteren als Kindelement ein. Das wiederholen wir noch einmal. Wird in dieser Konstellation nun der äußere Block aktualisiert, werden auch alle Kindelemente aktualisiert. Dieses Verhalten kann man überprüfen, in dem man die Kommunikation im WicketAjaxDebug-Fenster betrachtet.

Deaktiviert man JavaScript und damit Ajax, dann funktioniert die Seite trotzdem, da dann die ganze Seite neu gerendert wird. Auf diese Weise kann man Webanwendungen mit Ajax-Unterstützung entwickeln, ohne dass man Nutzer, die aus welchen Gründen auch immer JavaScript deaktiviert haben, im Regen stehen lässt.

<html>
  <head>
    <title>AjaxMultiUpdate</title>
    <style type="text/css">
      .block
      {
        border:1px solid dashed;
      }
    </style>
  </head>
  <body>
    <h1>Ajax Test</h1>
    <div wicket:id="feedback"></div>
    
    <div wicket:id="ajaxUpdate" class="block">
      <span wicket:id="count">123</span> <a wicket:id="link">+1</a>
      <div wicket:id="ajaxUpdate" class="block">
        <span wicket:id="count">123</span> <a wicket:id="link">+1</a>
        <div wicket:id="ajaxUpdate" class="block">
          <span wicket:id="count">123</span> <a wicket:id="link">+1</a>
          
        </div>
      </div>
    </div>
  </body>
</html>

Dieses Beispiel offenbart wesentliche Unterschiede zwischen der Ajax-Integration von Wicket und anderen Frameworks:

• Wicket kann beliebig viele Komponenten innerhalb eines Request aktualisieren.
• Wicket kann die Aktualisierung optimieren.
• Auch bei deaktiviertem Javascript ist die Funktion der Anwendung gewährleistet.

Ich hatte in einem der letzten Beiträge eine Umfrage gestartet, um herauszufinden, welche Frameworks gerade wie intensiv eingesetzt werden. Natürlich ist das Ergebnis der Umfrage nicht mehr als ein Indiz, entspricht aber meinen Erwartungen.

Die erste Schwierigkeit, auf die man bei jedem Framework stößt, ist die Frage, ob es das Richtige für die Problemstellung ist. Dabei spielen natürlich verschiedene nicht technische Aspekte eine Rolle, die in die Entscheidung mit einfließen sollten. Anbei eine kleine Auswahl von Kriterien, die man in die Entscheidung einfließen lassen sollte:

• Ist das neue Framework eine Erweiterung meines Portfolios und sind mittel- und langfristig Synergieeffekte zu erwarten?
• Ist das neue Framework ein Ersatz für ein anderes im Einsatz befindliches Framework und wie kann eine Migrationsstrategie aussehen?
• Mit wieviel neuem muss ich mich beschäftigen? Wie steil ist die Lernkurve?
• Gibt es gute Dokumentationen (Bücher, Wiki, gut lesbarer Quelltext, etc.)?
• Ist zu erwarten, dass die Verbreitung dieses Frameworks eher zu- oder abnimmt?

Das letzten Fragen befassen sich nur mit einem Ausschnitt der Problematik und sind doch schon für sich genommen recht komplex. Diese Fragen kann man allerdings schwer für jemand anderen, sondern meist nur halbwegs gut für sich selbst und seinen Verantwortungsbereich beantworten. Deshalb beziehe ich mich in der folgenden Übersicht eher auf technische und organisatorische Aspekte, die aus den Erfahrungen im Umgang mit diesen Frameworks resultieren und daher natürlich subjektiv sind. Trotzdem glaube ich, dass die Einschätzung eine Hilfe für jeden sein kann, der sich mit den betreffenden Frameworks nicht beschäftigen konnte und sich trotzdem für eins einscheiden muss.

Grails

Grails ist ein an "Ruby on Rails" angelegtes Framework, was Groovy als Programmiersprache benutzt. Dinge die für Grails sprechen:

• Grails bringt alles mit, was man für eine Webanwendung braucht. Datenbank, Services, Präsentation, Ajax, etc.
• Es ist einfach, ausgehend von einer Datenbank mit Daten Anwendungen zu entwickeln, die diese Daten pflegen können.
• Die Java-Integration in Grails/Groovy ist sehr gut. Man kann als recht einfach auf bestehende Bibliotheken zurückgreifen.

Dinge die eher gegen Grails sprechen:

• Groovy ist eine dynamisch typisierte Sprache. Das hat Auswirkungen auf die IDE-Unterstützung und den Entwicklungsprozess.
• Grails benutzt für die verschiedenen Aspekte einer Anwendung etablierte Frameworks, die immer dann hervorscheinen, wenn man ein Problem hat und man sich dann nicht nur mit diesem Framework, sondern vor allem mit der Integration in Groovy beschäftigen muss.
• Grailsprojekte tendieren nicht zur Modularisierung. Ein nachträgliches Herauslösen von Funktionalität ist eher schwer.
• Wer auf eine gute Ajax-Unterstützung baut, der sollte wissen, dass Grails per Ajax nur einen Block auf der Seite aktualisieren kann. Es gibt Lösungen, die dieses Limit umgehen. Allerdings ist es überraschend, dass diese Lösungen es bisher nicht in den Grails-Kern geschafft haben.

Wer mit Grails Anwendung entwickeln möchte, der kann im Moment eigentlich nur auf IDEA und Netbeans als Entwicklungsumgebung zurückgreifen. Mit Grails lassen sich vor allem Probleme gut lösen, die genau in die Grails-Vorgehensweise passen: Datenbank anlegen, Tabellen definieren, Eingabemasken für den Datenzugriff generieren, eigene Ansichten mit eigenen Abfragen erstellen. Das ganze mit ein wenig Ajax würzen. Fertig.

Werden die Anwendungen in der Darstellung komplex, fängt es an, auch in Grails komplexer zu werden (und unterscheidet sich damit nicht von Ruby on Rails). Wenn der Fokus der Entwicklung eher in der Präsentationsschicht liegt, kann sich ein Framework lohnen, dass da seine Stärken hat. Grails ist IMHO vergleichbar mit einem etwas besseren Ansatz als Java Server Pages.

Ein in meinen Augen wichtiger Aspekt ist die fehlende Typsicherheit. Das bedeutet, dass nicht nur der letztmögliche Zeitpunkt, sondern oft auch der frühestmögliche Zeitpunkt, an dem ein Fehler sichtbar wird, der ist, wenn die Anwendung gestartet wurde und die fehlerhafte Funktion das erste mal aufgerufen wird. Dieser Fehler ist dann leicht zu beheben, weil es im Gegensatz zu anderen eher Java-basierten Frameworks keinen Server-Neustart nach sich zieht (meist nicht). Um solche Fehler in den Griff zu bekommen, müsste man dann aber entsprechende Unit-Tests erstellen. Wenn man der Argumentation von Robert Martin folgt, dann ist dieser Ansatz (dem auch jede PHP-Anwendung folgt) nicht mit TDD vereinbar, noch Clean Code ist.

Man kann Grails nutzen, man muss nur wissen, worauf man sich einlässt.

GWT

Im Gegensatz zu Grails benutzt GWT Java als Programmiersprache. GWT unterscheidet sich von allen anderen Frameworks dadurch, dass der Schwerpunkt der Entwicklung von GWT-Anwendungen darin liegt, einen wesentlichen Anteil der Anwendung per Javascript im Browser des Anwenders laufen zu lassen. Wenn man in Grails eine Liste neu sortiert hat, konnte man dieses Ergebnis per Ajax auf der Seite ersetzen lassen. Bei GWT ist es möglich, diese Liste nur im Browser neu zu sortieren, ohne das dadurch eine Verbindung zum Server aufgebaut werden müsste. Man kann komplexe Anwendungen schreiben, die vollständig im Browser laufen und keinerlei Verbindung zum Server aufbauen müssen. Man könnte die selbe Anwendung direkt in Javascript entwickeln.

Da Google GWT für eigenen Anwendungen nutzt, ist der Ansatz, den Google damit verfolgt, recht offensichtlich. Alles, was nicht auf dem Server, sondern im Browser des Users ausgeführt wird, belastet die eigenen Server nicht. Wenn man Probleme dieser Kategorie erwartet, könnte GWT eine Lösung sein. Allerdings bedeutet das, dass der Nutzer ohne aktiviertes Javascript überhaupt nichts zu sehen bekommt.

Anwendungen, die mit GWT entwickelt wurden, verhalten sich eher wie Flash-Anwendungen oder Applets, man kann sie auf beliebigen Seiten einbinden. Das bedeutet aber auch, dass eine Suchmaschine (auch Google in diesem Fall) nichts von der Anwendung sieht. Wer also Webanwendungen entwickeln möchte, die Inhalte auch für Suchmaschinen zur Verfügung stellen oder zu erwarten ist, dass Javascript deaktiviert sein könnte, sollte GWT nicht in Betracht ziehen.

Der GWT-Ansatz fordert natürlich Tribut. Der Entwicklungszyklus ist kompliziert, das der Javacode erst in Javascript kompiliert werden muss. Die Trennung in Client- und Servercode ist nicht ohne Weiteres nachvollziehbar. Die erste eigene Beispielanwendung ist mit Schmerzen verbunden und geht nicht leicht von der Hand.

Wer eher Desktop-orientierte Anwendungen entwickeln möchte, aber das Lastproblem, das man mit GWT lösen könnte, nicht für den anstehenden Themenkomplex als Problem identifiziert hat, der sollte sich vielleicht Vaadin ansehen. Der Unterschied zu GWT liegt im wesentlich einfacheren Entwicklungszyklus (der auf die Schmerzen verzichtet) und der bereits vorbereiteten Komponenten, die von Haus aus recht ansprechend aussehen. Vaadin benutzt GWT nur für die Darstellung und ist eher ein serverlastiges Framework. Die Vorteile, die GWT gerade im Lastbereich hat, werden durch Vaadin reduziert.

GWT eignet sich für Webanwendungen immer dann, wenn die Anwendung eher einen Service als Inhalte zur Verfügung stellt. Webanwendungen, die auf Inhalte setzen, die der Nutzer in Suchmaschinen findet und die Verlinkt werden können, eher auf andere Frameworks setzen.

Wicket

Wicket benutzt Java als Programmiersprache. Im Gegensatz zu JSF, Grails und Anderen, werden in den Html-Schnipseln, die für die Darstellung verantwortlich sind, kein Code benutzt. Alles wird mit Java realisiert. Das hört sich im ersten Moment wie ein Nachteil an, erweist sich spätestens bei Benutzung als Vorteil. Auf diese Weise kann man jede beliebige IDE einsetzen und von allen Möglichkeiten profitieren, die eine Entwicklungsumgebung in Bezug auf Java bereitstellt.

Wie bei GWT muss man sich bei allen anderen Aspekten einer Webanwendung mit der Auswahl der richtigen Frameworks beschäftigen und diese auf einander abstimmen. Allerdings kann man sich das ganze auch einfach machen und auf die selbe Frameworks wie Grails setzen. Einzig die Integration muss man selbst bewerkstelligen. Für Wicket gibt es eine gute Integration von Spring und damit Hibernate als Persistenzschicht.

Was Wicket fehlt (möchte man meinen), sind Komponenten, die bereits ein ansprechendes Layout mitbringen. Das ist allerdings auch nicht der Fokus von Wicket. Mit Wicket kann man von klassischen Web-1.0 Anwendungen bis zu Ajax-reichen Desktop-ähnlichen Anwendungen alles umsetzen. Die Komponentenarchitektur macht das ganze beherrschbar, die Anwendungen suchmaschinentauglich zu machen, ist ohne größere Aufwände (vor allen auch nachträglich) möglich.

Im Desktop-Bereich wird die Differenzierung jetzt etwas schwer: Wicket sollte man benutzen, wenn Suchmaschinenoptimierung ein Thema ist und die Anwendung auch ohne Ajax/Javascript funktionieren muss. Wenn man kein Lastproblem erwartet aber auf alle Fälle auf fertige, ansprechende Komponenten zurückgreifen möchte, benutzt man am besten Vaadin. Bei zu erwartenden Lastproblemen kann sich der Einsatz von GWT auszahlen.

Besonders bei Anwendungen die sich irgendwo zwischen Web-1.0 und Desktop befinden, oder einen großen Teil davon abdecken müssen, sollte man Wicket benutzten. Gerade in diesem Bereich kann Wicket seine Stärken ausspielen. Durch den OO-Ansatz von Wicket kann man jederzeit bestehende Komponenten umarbeiten, erweitern, vereinfachen oder aufteilen, so das man nach recht kurzer Zeit ein stabiles Grundgerüst an eigenen Komponenten besitzt, mit denen dann sehr schnell neue Entwicklungen realisiert werden können.

der Rest

Was ist mit den ganzen anderen Frameworks? Bisher konnte ich keine Punkte identifizieren, die nicht eins der erwähnten Frameworks nicht abbilden kann, so dass man auf dieses Framework weiterhin angewiesen ist. Da ich mir nicht alle Frameworks angesehen habe, fehlt natürlich das eine oder andere. In der folgenden Übersicht folgen meine Empfehlungen für eine Migration auf eines der auserwählten Frameworks:

• JSF: GWT, Vaadin oder Wicket
• Tapestry,Struts: Wicket
• PHP,JSP: Grails oder Wicket (je nachdem wie komplex da UI wird)

Schwere Entscheidung

Jetzt muss man sich nur noch entscheiden. Man sollte sich allerdings die Entscheidung nicht zu schwer machen, wenn man zwischen zwei geeigneten Kandidaten wählen muss. Es dient vielmehr dazu, ein besseres Fundament für die eigenen Entscheidung zu gießen. Wie oft ist man in den letzten Jahren einem Hype gefolgt, um dann feststellen zu müssen, dass es nicht das eine Framework gibt, dass alle Probleme lösen kann. Im Zweifel fährt man besser, wenn man auch einmal "nein" sagt und bewusst auf ein Feature verzichtet.

Feedback

Rückmeldungen sind natürlich willkommen. Aspekte, die ich vergessen habe, pflege ich gern ein, ansonsten ist ja genug Platz in den Kommentaren, um die eigene Sichtweise und Erfahrung darzulegen.

Ich habe mir das Scala Webframework Lift angesehen und finde, es ist zu kompliziert. Aber ich habe mir heute morgen auch wieder ein paar Möglichkeiten angesehen, die Scala so bietet und frage mich, ob man nicht (mit etwas Hilfe) ein Stack erstellen könnte, der Scala als Basissprache benutzt und sonst sich aber eher von Rails/Grails inspirieren lassen könnte. Für das UI käme natürlich Wicket in Frage.

Ich glaube, das wäre reizvoll, spannend und wichtig: sehr produktiv.

p.s.: wenn es sowas schon gibt, bitte gerne einen Hinweis.

Man lernt ja jeden Tag etwas neues. Gestern habe ich gelernt, dass Grails von Haus aus nur ein Element per Ajax austauschen kann. Man klickt auf einen Link und kann dann z.B. den Inhalt eines DIV-Tags ersetzten, ergänzen oder was auch immer. Das ist alles ganz nett und einfach. Ändert sich aber durch eine Interaktion mehr als ein Element auf der Seite, fängt es an kompliziert zu werden. Wobei kompliziert eigentlich nicht das richtige Wort ist, denn man muss diese fehlende Funktionalität selbst ergänzen.

Es ist unzweifelhaft möglich, so das gewünschte Ziel zu erreichen. Aber ich finde es spannend, dass es eine IMHO derart triviale Anforderung nicht in den "Grails-Standard" geschafft hat. In Wicket füge ich die Komponenten, die aktualisiert werden müssen, einfach zu einer Liste hinzu. Ich muss mich nicht darum kümmern, was dann genau passiert.

Festzuhalten bleiben für mich die Punkte, die für mich eher gegen einen Einsatz von Grails sprechen:

• Ajax Update nur für ein Element möglich.
• Spring Security ist pfadbasiert - das ist IMHO ein extrem limitierter Ansatz.
• Taglibs sind kein Ersatz für Komponenten.

Grails hat Stärken.. aber ich bezweifle zunehmend, dass in Projekten, die mit Grails angefangen wurden, Grails diese positiven Effekte aus dem Projektstart auch auf lange Sicht ausspielen kann.

Update:

Immerhin habe ich gerade wieder gelernt, dass man Spring Security auch mit Annotationen am Controller benutzen kann, so dass man die Pfade nicht von Hand aktualisieren muss, wenn man etwas umbaut.

Das ich hier vielleicht Wicket und Grails vergleiche, obwohl die beiden Technologien nicht so einfach vergleichbar sind, bezieht sich in dieser Kritik nur auf den View-Layer. Es gibt sehr viele Dinge, die ich recht cool finde, an Grails. Aber um View-Layer bin ich einfach besseres gewohnt.

Wicket 1.4 nähert sich der Fertigstellung. Das ist ein gutes Zeichen, auch wenn ich Wicket 1.4-rc2 bereits längere Zeit ohne Probleme produktiv einsetze. Dieses Jahr wird ein Wicket-Jahr, denn so langsam beschäftigen sich immer mehr Entwickler mit dem Framework. Außerdem erscheinen in diesem Jahr einige Bücher rund um Wicket, so dass man gespannt sein darf, welche Auswirkung aktuelle Literatur zu diesem Thema haben wird.

Für mich steht diese Jahr auch im Zeichen von Scala. Die IDE-Unterstützung verbessert sich zunehmen, so dass man jetzt schon wieder zwischen Eclipse und Netbeans wählen kann. Wenn man dann Scala mit Wicket kombiniert, könnte man bei der Umsetzungsgeschwindigkeit auch Frameworks wie Grails den Platz auch gerade bei einfachen Projekten streitig machen. Das Wicket gerade bei komplexen Projekten punktet hat sich zwar auch noch nicht überall herumgesprochen, aber je mehr Anwendungen mit Wicket realisiert werden, desto schwieriger kann man diese Entwicklung ignorieren.

Damit bleiben für mich zwei Technologien übrig, mit denen man sinnvoll Java-basierte Webanwendungen entwickeln kann: GWT und Wicket. Für alle anderen Frameworks gibt es eigentlich keine Berechtigung, weil es keine guten Gründe mehr gibt, die für deren Einsatz sprechen. Wer andere Meinung ist, kann sich ja in einem Kommentar beschweren.

Am Ende des Jahres werden wir sehen, wie dicht ich dran lag:)