Apache Wicket – Eclipse RCP – Databinding – Fight!

Hallo,

ich bin ein großer Fan des Wicket Frameworks, und da ich aus eigener Erfahrung weiß, wie schwer einem der Einstieg fallen kann (das Framework selbst ist sehr übersichtlich und leicht erlernbar, allerdings gibt es einige Fallstricke, die es zu beachten gilt), habe ich mich entschlossen, einige Best-Practices einfach nieder zu schreiben, die aus meiner Sicht für die Arbeit mit dem Framework relevant sind.

Für Anregungen, Kritik, Verbesserungen und Ergänzungen bin ich natürlich jederzeit sehr offen und dankbar.
Ich hoffe, ich kann dem Einen oder Anderen den Einstieg in das Framework erleichtern und ggf. den Wicket hin zum Wicket-Framework ein wenig ebnen.

Der Artikel wird Schritt für Schritt ergänzt, ist also momentan noch eine erste Draft – Version.

#Pitfall 1 : Wicket Models

Bei der Verwendung von Models kann man viel falsch, aber auch viel richtig machen. Models sind DAS Konzept in Wicket für den Zugriff auf die zugrundeliegenden Domain-Daten.
Einsteiger in das Framework fragen sich des öfteren, warum man in Wicket einen weiteren Abstraktionslayer braucht, wo man doch auch direkt auf die Domain-Daten zugreifen kann.

Die Antwort ist aus meiner Sicht sehr einfach und auch eindeutig:
Weil die Verwendung von Wicket-Models zu viele Vorteile bietet, um diese einfach ignorieren zu können, als da wären beispielsweise:

  • Automatisches Databinding von Domain-Model-Properties an Widgets (wie beispielsweise Textfelder) durch PropertyModels
  • Signifikante Reduktion von Codezeilen durch CompoundPropertyModels
  • Lazy-Loading von Domaindaten durch LoadableDetachableModels
  • I18N-Support durch ResourceModels
  • Variablensubstiutionen durch StringResourceModels
  • Kombination der wichtigsten o.g. Features durch Model-Chaining

Ich möchte das gerne mal an einem Beispiel darstellen, ich bin neben dem Wicket-Framework auch ein großer Fan der Eclipse RCP Plattform und habe hier schon einige Projekte gemacht. Bevor ich Wicket kennengelernt habe, war ich ebenfalls ein großer Fan des Eclipse Databinding-Frameworks.

Das Eclipse Databinding Framework sieht ungefähr so aus:

public class Person implements PropertyChangeListener {
     private PropertyChangeSupport support;
     public Person(){
         support = new PropertyChangeSupport(this);
     }

     public void setName(String name){
           propertyChangeSupport.firePropertyChange("name", this.name,
				this.name = name);
     }
}

Damit das Framework über entsprechende Events benachrichtigt wird, müssen wir zunächst mal Anpassungen an unseren Domainobjekten vornehmen (Implementierung PropertyChangeSupport, feuern von Events wenn sich eine Property ändert etc.)
Das ist auch mehreren Gründen nicht optimal:

  • Die Domainobjekte werden durch Code verschmutzt, der nichts zur Fachlichkeit beiträgt
  • Änderungen an Domainobjekten sind nicht immer möglich (wenn diese zum Beispiel von einer anderen Abteilung entwickelt werden)
  • Domainobjekte werden durch den zusätzlichen Code fehleranfälliger.
  • Wir haben eine enge Kopplung unserer Domainobjekte an Implementierungsklassen aus dem JDK (PropertyChangeSupport etc..)

Dies sind alles Punkte, die ich als verantwortungs voller Softwareentwickler gerne vermeiden möchte.

Der Ansatz von Wicket ist hier ein sehr pragmatischer, denn die Person-Klasse sieht hier so aus:

public class Person {
    public Person(){}

    public void setName(String name){
        this.name = name;
    }
}

FÜr das Databinding selber muss nicht eine einzige Änderung an den Domainmodels vorgenommen werden.
Wicket bietet genau hierfür die zusätzliche Abstraktionsschicht, die über die Models realisiert ist.

Ein Binding eines Textfeldes an eine Property aus einem Domainobjekt kann beispielsweise so realisiert werden:


TextField<String> textField = new TextField<String>("myWicketId", new PropertyModel<String>(customer,"name");

Damit wird das Textfeld automatisch mit dem Attribut „name“ aus dem Customer verbunden.

Jetzt ist der Vergleich natürlich ein wenig unfair, da Wicket „bessere“ Voraussetzungen hat, Databinding einzusetzen als beispielsweise die RCP-Plattform, denn Wicket arbeitet im Web und damit auf dem zustandslosen HTTP-Protokoll und Ajax.

Jede Interaktion löst üblicherweise ein Refresh der UI-Komponenten aus (sei dies durch einen Page-Reload oder durch ein Update von Komponenten über Ajax).

Das bedeutet, Wicket ist nicht angewiesen auf Events, die durch Modeländerungen realisiert werden.

RCP hingegen ist zustandsbehaftet, ein Submit löst keinen Refresh von Komponenten aus (es sei denn, man triggert dies manuell). Damit die Komponenten in einer RCP Applikation also über Änderungen in Modelwerten benachrichtigt werden, muss hier auf einen Eventmechanismus zurückgegriffen werden, und dies geschieht genau über den PropertyChangeSupport den ich zuvor beschrieben habe.

Trotzdem fühlt sich das Eclipse Databinding Framework in meinen Augen nicht besonders gut an. Es ist zu aufwendig und invasiv.

Im nächsten Artikel zu dem Thema versuche ich einen alternativen Ansatz für RCP vorzustellen, der sich an die Konzepte des Wicket Frameworks anlehnt.

Bis dahin!

Viel Spaß mit Wicket , RCP oder was euch sonst so umtreibt.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s