Auch wenn es anders kommt, als man sich denkt, wage ich hier doch mal ein paar Vorhersagen. Manches davon ist offensichtlich und wird vermutlich schon deshalb nicht eintreten, Anderes ist frei erfunden und hat damit die besten Chancen, zum Volltreffer zu werden.

Nachdem 2009 eigentlich ein Scala-Jahr war, wird es auch 2010 in diesem Bereich interessant bleiben. Zu meiner Überraschung konnte allerdings auch Java durch den Scala-Hype profitieren. Einige fühlten sich wohl durch die Möglichkeiten von Scala entsprechend angestachelt, dass selbst für Dinge wie Scala Traits Implementierungen (z.B. java-mixins) für Java geschrieben wurden. Java ist zwar etwas angestaubt aber eben noch nicht tot. Und was Google mit GWT und Android alles auf Basis von Java anstellt, zeigt deutlich, dass da noch Platz für Innovationen ist. Das bedeutet, dass es auch 2010 nicht verkehrt ist, auf Java zu setzen.

Nachdem JSF 2.0 wie zu erwarten war, nicht alle Probleme, die JSF bis jetzt angesammelt hat, lösen wird, gehe ich davon aus, dass wie schon 2009 immer mehr Projekte auch mit Wicket realisiert werden. Da Wicket als Basis schon sehr ausgereift ist, wird sich der Zustrom an Entwicklern vermutlich eher auf Integrationsthemen auswirken: Web-Worker, Javascript-Frameworks und andere noch unbekannte Entwicklungen. Ich erwarte außerdem (unabhängig von meinem eigenen Teilprojekt auf wicketstuff.org) ein paar Standardvorlagen für Wicket-Projekte.

Nachdem Groovy in der neuesten Version alle Sprachfeatures hat, die für eine saubere Wicket-Integration notwendig sind, wird es auch in diesem Bereich interessant. Die Bedenken, die ich trage, richten sich vielmehr an die Plattform Groovy/Grails an sich. Es gibt Entwicklungen, die bei mir Bauchschmerzen hervorrufen (Grape – Dependency Management als Annotation auf einem Import – WTF)), die merkwürdig sind und auf die Frage “Warum?” vermutlich nur mit einem “Weil es geht.” beantwortet werden.

Alles in Allem, es bleibt und wird spannend. Ich wünsche allen (unabhängig von der technologischen Präferenz) ein gutes und erfolgreiches Jahr.

Andere Beiträge

• 12. September 2009 -- Entscheidungshilfe Webframework
• 11. Mai 2009 -- Die Ruhe vor dem Sturm
• 29. April 2011 -- Wicket – Back Button zuverlässig erkennen

Wicket Struktur – Übersicht aus der Arbeit am Buch

Andere Beiträge

• 16. Oktober 2009 -- Wicket Komponentenübersicht
• 29. April 2011 -- Wicket – Back Button zuverlässig erkennen
• 24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB

In einem kleinen Beispiel möchte ich veranschaulichen, wie die verschiedenen Model-Klassen zum Einsatz kommen können und warum man immer Modelle benutzen sollte.

Wir erstellen zuerst eine Model-Klasse, die eine Liste von Ergebnissen liefert. In diesem Fall werden die Einträge zwar fest kodiert, könnten aber genauso gut aus der Datenbank kommen.

package de.wicketpraxis.web.blog.pages.migration.model;
 
public class Result
{
  String _name;
 
  Double _betrag;
 
  public Result(String name, double betrag)
  {
    _name=name;
    _betrag=betrag;
  }
 
  public String getName()
  {
    return _name;
  }
 
  public Double getBetrag()
  {
    return _betrag;
  }
}

package de.wicketpraxis.web.blog.pages.migration.model;
 
import java.util.ArrayList;
import java.util.List;
 
import org.apache.wicket.model.LoadableDetachableModel;
 
public class ResultListModel extends LoadableDetachableModel<List<Result>>
{
  @Override
  protected List<Result> load()
  {
    List<Result> ret=new ArrayList<Result>();
    ret.add(new Result("Popcorn",3.15));
    ret.add(new Result("Eis",2.80));
    ret.add(new Result("Eintritt",5.50));
    return ret;
  }
}

Das LoadableDetachableModel ist immer dann die beste Wahl, wenn Daten dynamisch erzeugt werden sollen und jedes mal sicher gestellt werden soll, dass die aktuellsten Daten verwendet werden. Wir das Model während eines Request geladen, werden die Daten so lange vorgehalten, bis die detach()-Methode aufgerufen wird, und die Liste zurückgesetzt wird. Das Model liefert uns in diesem Fall 3 Datensätze der Result-Klasse.

Die Beispielliste ist eine Liste von Posten auf einer Rechnung. Wir möchten aber zum Betrag auch noch den MwSt-Anteil ausweisen. Dazu schreiben wir ein allgemeines Model, dass von einer Erweiterung des LoadableDetachableModel abgeleitet ist: CascadingLoadableDetachableModel.

package de.wicketpraxis.web.blog.pages.migration.model;
 
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.LoadableDetachableModel;
 
import de.wicketpraxis.web.blog.model.CascadingLoadableDetachableModel;
 
public class MwStAnteilModel extends CascadingLoadableDetachableModel<Double, Double>
{
  static final Double MWST=19.0;
 
  public MwStAnteilModel(IModel<? extends Double> parent)
  {
    super(parent);
  }
 
  @Override
  protected Double load(Double brutto)
  {
    if (brutto!=null)
    {
      return brutto*MWST/100.0;
    }
    return null;
  }
}

Das Model entnimmt dem referenzierten Model den Betrag und ermittelt den MwSt-Anteil, den es seinerseits bereitstellt. Der Wert wird auch hier bis zum Aufruf von detach() gepuffert. Als Referenzmodell kann jede Klasse dienen, die IModel implementiert.

Jetzt fügen wir die Bestandteile zusammen:

package de.wicketpraxis.web.blog.pages.migration.model;
 
import java.util.List;
 
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.list.ListItem;
import org.apache.wicket.markup.html.list.PropertyListView;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.PropertyModel;
 
import de.wicketpraxis.web.blog.model.CascadingLoadableDetachableModel;
 
public class SomeModelsPage extends WebPage
{
  public SomeModelsPage()
  {
    ResultListModel resultList=new ResultListModel();
 
    add(new PropertyListView<Result>("list",resultList)
    {
      @Override
      protected void populateItem(ListItem<Result> item)
      {
        IModel<Result> model = item.getModel();
        item.add(new Label("name",new PropertyModel<String>(model,"name")));
        item.add(new Label("betrag"));
        item.add(new Label("mwst",new MwStAnteilModel(new PropertyModel<Double>(model,"betrag"))));
      }
    });
 
    IModel<Double> summeModel = new CascadingLoadableDetachableModel<Double, List<Result>>(resultList)
    {
      @Override
      protected Double load(List<Result> liste)
      {
        if (liste!=null)
        {
          double summe=0;
          for (Result r : liste)
          {
            summe=summe+r.getBetrag();
          }
          return summe;
        }
        return null;
      }
    };
 
    add(new Label("summe",summeModel));
    add(new Label("mwst",new MwStAnteilModel(summeModel))); 
  }
}

Zuerst erstellen wir eines Instanz des ResultListModel. Die Ergebnisliste wird durch eine PropertyListView dargestellt. Der Unterschied zur ListView-Komponente besteht darin, dass bei Komponenten ohne eigenes Model die Id als Property-Expression herangezogen wird, um das Model für die Anzeige der Daten zu ermitteln. Die Schreibarbeit, die man für das Label “name” aufwenden müsste, kann man auf diese Weise erheblich reduzieren. Wie man beim Label mit der Id “mwst” erkennen kann, können die Modelle beliebig geschachtelt werden.

Um die Summe aller Einträge zu ermitteln, könnten wir jetzt die Ergebnisliste durchgehen und die Summe berechnen. Doch der Konstruktor einer Komponente wird ja nur einmal aufgerufen. Ändert sich durch eine Aktion auf der Seite oder in einer Komponente etwas an den zugrunde liegenden Daten, dann wird die Summe so nicht automatisch aktualisiert. Daher erstellen wir ein Model, dass diese Berechnung immer wieder durchführt. Dann können wir die aktuelle Summe und auch hierfür den MwSt-Anteil anzeigen lassen. Sollte sich an den Daten in der Datenbank etwas ändern, dann werden automatisch alle angezeigten Werte neu berechnet.

In diesem Beispiel sind mehrere wichtige Themen versteckt:

• Alle Daten sollten in einem Model abgelegt werden. Daten sollten nicht im Konstruktor einer Komponente aufbereitet werden.
• Für Modelle, die nicht an eine Komponente gebunden sind, wird die detach()-Methode nicht automatisch aufgerufen. Die CascadingLoadableDetachableModel-Klasse behandelt diesen Umstand entsprechend.
• Model-Klassen kann man wiederverwenden.
• Das Beispiel veranschaulicht, wie man z.B. die Summe aller sichtbaren Einträge über den Model-Weg ermitteln kann.

Ich hoffe, ich konnte wieder etwas Licht in das Dunkel rund um die Model-Klassen bringen. Fragen und Anregungen gerne in dem Kommentaren oder per Email.

Andere Beiträge

• 28. Oktober 2009 -- Wicket Model Transformation
• 3. Januar 2009 -- Modell-Referenzen
• 4. November 2009 -- PropertyModel – einfach ist nicht immer gut

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.

Wicket Ajax Debug Window

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.

Andere Beiträge

• 21. Juli 2009 -- Grails Ajax Update zu kompliziert…
• 9. April 2010 -- Wicket – AbstractEvent Update
• 7. März 2010 -- Wicket Heatmap – Ajax mit Parametern

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.

Andere Beiträge

• 11. Mai 2009 -- Die Ruhe vor dem Sturm
• 6. September 2009 -- Migration zu Wicket
• 2. Januar 2010 -- Anfang und Ende

Als erstes erstellen wir eine JavaBean in der das Formular die Daten ablegt:

package de.wicketpraxis.web.blog.pages.questions.migration.forms;
 
import java.io.Serializable;
 
public class FormBean implements Serializable
{
  String _name;
 
  public String getName()
  {
    return _name;
  }
 
  public void setName(String name)
  {
    _name = name;
  }
}

Nichts besonderes. Die Bean hat das Attribut “Name”. Erstellen wir eine Seite, die über ein Formular diese Bean mit Werten füllt:

package de.wicketpraxis.web.blog.pages.questions.migration.forms;
 
import java.io.Serializable;
 
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.CompoundPropertyModel;
 
public class MinimalFormPage extends WebPage
{
  public MinimalFormPage()
  {
    Form<FormBean> form = new Form<FormBean>("form",new CompoundPropertyModel<FormBean>(new FormBean()));
 
    form.add(new TextField<String>("Name"));
 
    add(form);
  }
}

Wie wir sehen, wird ein Formular eingebunden und in dieses Formular ein Textfeld für das Attribut benutzt. Damit ist dieses Beispiel funktionsfähig. Es macht nur nicht besonders viel. Was aber gut zu erkennen ist:

• es wird keine Ergebnisseite benötigt
• es muss keine Methode überschrieben werden, um die Eingabedaten in der Bean abzulegen

Das Markup ist ebenfalls recht einfach:

<html>
  <head>
    <title>MinimalFormPage</title>
  </head>
  <body>
    <form wicket:id="form">
      Name <input wicket:id="Name"><br>
      <input type="submit" value="Absenden">
    </form>
  </body>
</html>

Interessant: der Submit-Button hat in diesem Beispiel keine Entsprechung als Wicket-Komponente. Das Formular wird trotzdem abgeschickt.

Komplexes Beispiel

Kommen wir nun zu einem etwas komplexeren Beispiel, dass eine Ergebnisseite verwendet. Dabei an dieser Stelle nocheinmal der Hinweis: die Ergebnisseite wird verwendet, weil wir das in diesem Beispiel so wollten. Alles was auf der Ergebnisseite dargestellt werden kann, könnte man auch ganz einfach auf der Seite darstellen, auf der auch das Formular eingebunden ist.

Als erstes erstellen wir die Ergebnisseite:

package de.wicketpraxis.web.blog.pages.questions.migration.forms;
 
import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
 
public class ResultPage extends WebPage
{
  public ResultPage(String name)
  {
    init(name);
  }
 
  public ResultPage(PageParameters pageParameters)
  {
    init(pageParameters.getString("Name"));
  }
 
  protected void init(String name)
  {
    add(new Label("name",name));
  }
}

<html>
  <head>
    <title>ResultPage</title>
  </head>
  <body>
    Name <span wicket:id="name"></span>
  </body>
</html>

Die Seite besitzt zwei Konstruktoren. Der erste erwartet einen String als Parameter, der zweite wertet die Seitenparameter aus (wenn die Seite z.B. mit ?Name=klaus aufgerufen wird). Der Wert wird durch das Label zur Anzeige gebracht.

Jetzt die Formularseite:

package de.wicketpraxis.web.blog.pages.questions.migration.forms;
 
import java.io.Serializable;
import java.util.HashMap;
import java.util.Map;
 
import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.CompoundPropertyModel;
 
public class KomplexFormPage extends WebPage
{
  public KomplexFormPage()
  {
    add(new FeedbackPanel("feedback"));
 
    Form<FormBean> form = new Form<FormBean>("form",new CompoundPropertyModel<FormBean>(new FormBean()))
    {
      @Override
      protected void onSubmit()
      {
        // Variante 1
        setResponsePage(new ResultPage(getModelObject().getName()));
 
        // Variante 2
        Map<String,String> map=new HashMap<String, String>();
        map.put("Name", getModelObject().getName());
        setResponsePage(ResultPage.class, new PageParameters(map));
 
        // Variante ?
      }
    };
 
    form.add(new TextField<String>("Name").setRequired(true));
 
    add(form);
  }
}

Wir haben in diesem Beispiel ein FeedbackPanel hinzugefügt, da wir auch das Textfeld zum Pflichtfeld gemacht haben. Ohne FeedbackPanel kommt sonst der Hinweis, dass man etwas eingeben muss, nicht zur Anzeige. Ansonsten haben wir die onSubmit-Methode überschrieben, die die Ergebnisseite aufruft. Dabei können wir zum einen eine Instanz der Seite erstellen, in dem wir (vorrausgesetzt es gibt einen passenden Konstruktor) den/die gewünschten Parameter direkt übergeben. Das wir in diesem Beispiel nur ein String übergeben, soll nicht darüber hinwegtäuschen, dass jedes beliebige (also auch weit komplexere) Objekte übergeben werden können.

Die zweite Variante verpackt den Parameter in einen Seitenparameter und springt die Seite dann über eine passende Url an. In diesem Fall werden natürlich die übergebenen Parameter für den Nutzer sichtbar. Das entspricht auch eher dem klassischen Verständnis einer Formularbehandlung in anderen Frameworks. Der Unterschied besteht allerdings schon darin, dass an dieser Stelle die Formularbehandlung bereits abgeschlossen ist und wir nur noch einmal absichtlich auf eine andere Seite springen.

Daher ist die letzte Variante auch nur mit einem Fragezeichen versehen. Wenn nichts dafür spricht, dass man eine wie auch immer geartete Ergebnisseite benötigt, kann man diese auch weglassen. Man sollte vielmehr darauf zurückgreifen, dass man Komponenten ein und ausblendet, wenn man das Formular nach erfolgreichem Ausfüllen nicht mehr anzeigen möchte.

Zusammenfassung

Ich hoffe, ich konnte zeigen, dass man sich vom dem klassischen Konzept einer Formularseite trennen muss und die Formularverarbeitung in Wicket ihre Entsprechung vermutlich eher in Swing findet.

Andere Beiträge

• 11. Dezember 2009 -- Wicket Form Submit – mit und ohne Ajax
• 5. Februar 2010 -- Wicket – kombiniertes AutoCompleteBehavoir
• 2. September 2009 -- Datenbankeinträge auswählen mit der CheckGroup

Er größte Fehler, den man bei einem Wechsel zu Wicket (und vermutlich bei jedem Wechsel einer Technologie) macht, besteht darin, das man versucht ein altes Problem mit neuer Technik auf alte Weise zu lösen. Das kann nicht funktionieren.

Beispiel

Wenn man Webanwendungen mit JSF, JSP, Struts oder anderen Frameworks entwickelt, tendiert man dazu, dass der Anwendungszustand zu einem wesentlichen Teil über Seitenparameter transportiert wird. Das hat verschiedene Ursachen (z.B. Suchmaschinenoptimierung, Seitenpufferung). Seiten, die besonders häufig abgerufen wurden, sollten gepuffert werden können. Das heißt, für eine bestimmte Url erhielt man immer den selben Inhalt. Es wurde teilweise ohne jede Nutzersession gearbeitet.

Diese Anforderung ist mit Wicket lösbar, aber der falsche Weg. Zu behaupten, es ginge mit Wicket spontan ganz einfach, ist aber ebenso falsch. Doch der Weg zu einer guten Lösung ist nicht weit. Als aller erstes musste ich mich davon verabschieden, dass eine Wicketseite (die auch Ajax verwendet) gepuffert werden kann. Wenn das Erstellen von Teilen der Seite zu zeitaufwendig ist, muss man durch das Puffern von Ergebnissen dem ganzen entgegenwirken. Aber im Unterschied zur alten Lösung wird nicht mehr die ganze Seite, sondern nur noch die Daten der nötigen Teilergebnisse gepuffert. Das ist auch sehr viele Arten sehr viel geschickter.

Ausblick

Dieses erste Beispiel veranschaulicht sehr gut, warum es gut ist, sich gerade auch mit den Grundlagen von Wicket zu beschäftigen. Ich den nächsten Artikeln werde ich weitere Beispiele erläutern und aufzeigen, wie man von der alten Lösung für ein Problem zu einer neuen Lösung mit Wicket kommt.

Wer möchte, kann mir seine Fragestellung zukommen lassen. Ich kann diese Fragestellungen dann in die Artikel einfließen lassen.

Andere Beiträge

• 12. September 2009 -- Entscheidungshilfe Webframework
• 11. Mai 2009 -- Die Ruhe vor dem Sturm
• 29. April 2011 -- Wicket – Back Button zuverlässig erkennen