wicket praxis » Refactoring

Wicket – Flexibilität mit Factories

michael — Thu, 15 Jul 2010 07:13:46 +0000

Komplexe Komponenten entstehen in Wicket durch das zusammenfügen von einfacheren Komponenten. Dabei werden die verwendeten Komponenten direkt adressiert. Nach außen ist nicht sichtbar, wie sich eine Komponente zusammensetzt. Um von dieser Komponente eine leicht abgewandelte Form zu erstellen, kann man auf z.B. Vererbung zurückgreifen, Komponenten ausblenden, das Markup überschreiben. Je mehr Variationen nötig sind, desto komplizierter wird der Aufbau. Der Aufwand steigt erheblich an.

Einen Ausweg aus dieser Situation könnte die Verwendung von Factories liefern. Dazu benötigen wir ein sehr einfach gehaltenes Interface:

package de.wicketpraxis.web.blog.pages.questions.factories;
 
import org.apache.wicket.Component;
 
public interface IComponentFactory<T extends Component>
{
  T newComponent(String id);
}

Eine einfach Implementierung, die immer ein Label mit einem bestimmten Text liefert, können wir wie folgt implementieren:

package de.wicketpraxis.web.blog.pages.questions.factories;
 
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.model.IModel;
 
public class LabelFactory implements IComponentFactory<Label>
{
  IModel _model;
 
  public LabelFactory(IModel model)
  {
    _model = model;
  }
 
  public Label newComponent(String id)
  {
    return new Label(id,_model);
  }
}

Wir übergeben hierbei ein Model, das durch das Label angezeigt wird. Soll ein anderer Text angezeigt werden, muss man dafür eine neue Factory erstellen. Bis jetzt ist noch kein Vorteil dieser Lösung absehbar. Deshalb steigern wir etwas die Komplexität. Wir erstellen eine Factory, die einen Rahmen um eine Komponente ziehen kann. Dabei wird für die Darstellung das style-Attribut erweitert.

package de.wicketpraxis.web.blog.pages.questions.factories;
 
import org.apache.wicket.AttributeModifier;
import org.apache.wicket.Component;
import org.apache.wicket.behavior.AttributeAppender;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.model.IModel;
 
public class BorderPanelFactory implements IComponentFactory<Panel>
{
  private final IComponentFactory extends Component> _content;
  private final IModel<String> _style;
 
  public BorderPanelFactory(IComponentFactory extends Component> content, IModel<String> style)
  {
    _content = content;
    _style = style;
  }
 
  public Panel newComponent(String id)
  {
    return new BorderPanel(id, _content, _style);
  }
 
  static class BorderPanel extends Panel
  {
    public BorderPanel(String id,IComponentFactory extends Component> content,IModel<String> style)
    {
      super(id);
 
      WebMarkupContainer border=new WebMarkupContainer("border");
      border.add(content.newComponent("content"));
      border.add(new AttributeAppender("style", true, style,";"));
      add(border);
    }
  }
}

Wir übergeben daher eine Factory, die Komponenten erzeugt und ein Model, dass die Styleattribute beinhaltet. In dem Panel, was innerhalb der Factory erzeugt wird, wir dann eine Komponente eingebunden (“content”), die aus der übergebenen Factory kommt. Wir benötigen noch eine passende Markup-Datei (BorderPanelFactory$BorderPanel.html):


  <div wicket:id="border" style="padding: 8px">
    id="content"></wicket:container>
  </div>
</wicket:panel>

Um zu demonstrieren, welche Flexibilität man mit diesen wenigen Klassen bereits erreicht hat, verwenden wir beide Factories in einem Beispiel:

package de.wicketpraxis.web.blog.pages.questions.factories;
 
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.model.Model;
 
public class ComponentFactoryPage extends WebPage
{
  public ComponentFactoryPage()
  {
    Model<String> redBorderStyle = Model.of("border:1px solid red; background-color: #fff0f0;");
    Model<String> greenBorderStyle = Model.of("border:1px solid green; background-color: #f0fff0;");
    Model<String> blueBorderStyle = Model.of("border:1px solid blue; background-color: #f0f0ff;");
 
    LabelFactory haveFunLabelFactory = new LabelFactory(Model.of("Have Fun"));
 
    BorderPanelFactory redBorderHasFunFactory = new BorderPanelFactory(haveFunLabelFactory,redBorderStyle);
    BorderPanelFactory greenBorderWrapsRedFactory = new BorderPanelFactory(redBorderHasFunFactory,greenBorderStyle);
    BorderPanelFactory blueBorderWrapsAllFactory = new BorderPanelFactory(greenBorderWrapsRedFactory,blueBorderStyle);
 
    add(blueBorderWrapsAllFactory.newComponent("element"));
  }
}

Wir erstellen 3 Modelle mit unterschiedlichen Werten für das style-Attribut. Um etwas Text anzuzeigen benutzen wir die LabelFactory. Danach werden drei BorderPanelFactory-Instanzen erzeugt, die eine andere Factory “umwickelt”. Zum Schluss wird ein Element erzeugt und in der Seite benutzt. Das Markup ist entsprechend einfach:

<html>
  <head>
    <title>ComponentFactory Page</title>
  </head>
  <body>
    id="element"></wicket:container>
  </body>
</html>

Das Ergebnis sieht dann wie folgt aus:

Um zu zeigen, wie schnell die Möglichkeiten wachsen, die man mit diesem Ansatz abdecken kann, erstellen wir eine weitere Factory. In diesem Fall möchten wir zwei Elemente nebeneinander dargestellen:

package de.wicketpraxis.web.blog.pages.questions.factories;
 
import org.apache.wicket.Component;
import org.apache.wicket.markup.html.panel.Panel;
 
public class TwoInARowFactory implements IComponentFactory<Component>
{
  private final IComponentFactory extends Component> _left;
  private final IComponentFactory extends Component> _right;
 
  public TwoInARowFactory(IComponentFactory extends Component> left, IComponentFactory extends Component> right)
  {
    _left = left;
    _right = right;
  }
 
  public Component newComponent(String id)
  {
    return new ContainerPanel(id, _left, _right);
  }
 
  static class ContainerPanel extends Panel
  {
    public ContainerPanel(String id,IComponentFactory extends Component> left, IComponentFactory extends Component> right)
    {
      super(id);
 
      add(left.newComponent("left"));
      add(right.newComponent("right"));
    }
  }
}

Es werden daher zwei Factories übergeben, die dann für die Erzeugung des linken und des rechten Elements zuständig sind. Das Markup benutzt der Einfachheit halber Html-Tabellen für die Anordnung:


  <table>
    <tr>
      <td>id="left"></wicket:container></td>
      <td>id="right"></wicket:container></td>
    </tr>
  </table>
</wicket:panel>

Unsere Seitenklasse ergänzen wir entsprechend:

package de.wicketpraxis.web.blog.pages.questions.factories;
 
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.model.Model;
 
public class ComponentFactoryPage extends WebPage
{
  public ComponentFactoryPage()
  {
    Model<String> redBorderStyle = Model.of("border:1px solid red; background-color: #fff0f0;");
    Model<String> greenBorderStyle = Model.of("border:1px solid green; background-color: #f0fff0;");
    Model<String> blueBorderStyle = Model.of("border:1px solid blue; background-color: #f0f0ff;");
 
    LabelFactory haveFunLabelFactory = new LabelFactory(Model.of("Have Fun"));
 
    BorderPanelFactory redBorderHasFunFactory = new BorderPanelFactory(haveFunLabelFactory,redBorderStyle);
    BorderPanelFactory greenBorderWrapsRedFactory = new BorderPanelFactory(redBorderHasFunFactory,greenBorderStyle);
    BorderPanelFactory blueBorderWrapsAllFactory = new BorderPanelFactory(greenBorderWrapsRedFactory,blueBorderStyle);
 
    add(blueBorderWrapsAllFactory.newComponent("element"));
 
    TwoInARowFactory twoInARowFactory = new TwoInARowFactory(redBorderHasFunFactory, greenBorderWrapsRedFactory);
 
    add(twoInARowFactory.newComponent("two"));
  }
}

Das Markup muss ebenfalls angepasst werden:

<html>
  <head>
    <title>ComponentFactory Page</title>
  </head>
  <body>
    id="element"></wicket:container>
    id="two"></wicket:container>
  </body>
</html>

Das Ergebnis kann sich sehen lassen:

Wie man an diesem Beispiel sehr gut erkennen kann, liegt in diesem Ansatz sehr viel Potential, gerade wenn die Anforderungen an die Flexibilität sehr hoch sind. In Projekten, die eine hohe Flexibilität erforderten hat sich dieses System bereits erfolgreich bewährt. Dabei kommt eine Kombinationen aus dem “klassischen” und dem Factory-Ansatz zum Einsatz, wodurch sich die meisten Anforderungen wesentlich besser abdecken lassen.

Gibt es noch ganz andere Lösungsstrategien?

Share and Enjoy:

Andere Beiträge

5. Januar 2010 -- Wicket – lose Koppelung von Komponenten
16. Oktober 2009 -- Wicket Komponentenübersicht
14. April 2010 -- Wicket Eclipse Plugin – qwickie

Wicket – No TransparentResolver

michael — Wed, 20 Jan 2010 09:16:14 +0000

Wie ich im letzten Beitrag bereits angkündigt habe, kann man tatsächlich das TransparentResolver-Problem mit Hilfe der verzögerten Initialisierung lösen. Dazu muss die AbstractLazyPanel-Klasse nur ein wenig verändert werden.

package de.wicketpraxis.web.blog.pages.questions.transparent.lazy;
 
import org.apache.wicket.Component;
import org.apache.wicket.MarkupContainer;
import org.apache.wicket.markup.html.panel.Panel;
 
public abstract class AbstractLazyPanel extends Panel
{
  boolean _lazyInitCalled;
 
  public AbstractLazyPanel(String id)
  {
    super(id);
  }
 
  @Override
  protected void onBeforeRender()
  {
    if (!_lazyInitCalled)
    {
      _lazyInitCalled=true;
      lazyInit();
    }
    super.onBeforeRender();
  }
 
  protected abstract MarkupContainer lazyInit();
}

Die Methode lazyInit() liefert die Komponente zurück, unter der alle Kindkomponenten eingehangen werden müssen. Das sieht in eigenen Komponenten dann wie folgt aus:

package de.wicketpraxis.web.blog.pages.questions.transparent.lazy;
 
import org.apache.wicket.MarkupContainer;
import org.apache.wicket.markup.html.WebMarkupContainer;
 
public abstract class BasePanel extends AbstractLazyPanel
{
  public BasePanel(String id)
  {
    super(id);
  }
 
  @Override
  protected MarkupContainer lazyInit()
  {
    WebMarkupContainer border = new WebMarkupContainer("border");
    add(border);
    return border;
  }
}

Hier erstellen wir einen Container, den wir an ein div-Tag binden.


  Base
  <div style="border:1px solid blue" wicket:id="border">
    />
  </div>
  Base End
</wicket:panel>

Die davon abgeleitete Klasse sieht dann wie folgt aus:

package de.wicketpraxis.web.blog.pages.questions.transparent.lazy;
 
import org.apache.wicket.MarkupContainer;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.model.Model;
 
public class SubPanel extends BasePanel
{
  public SubPanel(String id)
  {
    super(id);
  }
 
  @Override
  protected MarkupContainer lazyInit()
  {
    MarkupContainer root = super.lazyInit();
    root.add(new Label("label",Model.of("Sub")));
    return root;
  }
}


  <span wicket:id="label"></span>
</wicket:extend>

Wie man sehen kann, wurde in diesem Beispiel sowohl Markup- als auch Komponentenvererbung benutzt. Trotzdem konnte auf den Einsatz von TransparentResolver verzichtet werden. Die Komponentenhierarchie entspricht der im Markup.

Ich hätte nicht gedacht, dass die Lösung so nahe liegt. Feedback wie immer willkommen…

Share and Enjoy:

Andere Beiträge

20. Januar 2010 -- Wicket – verzögerte Initialisierung
15. Juli 2010 -- Wicket – Flexibilität mit Factories
14. April 2010 -- Wicket Eclipse Plugin – qwickie

Wicket – verzögerte Initialisierung

michael — Wed, 20 Jan 2010 08:28:05 +0000

Nicht immer ist es möglich oder sinnvoll, im Konstruktor einer Komponente bereits die vollständige Komponentenstruktur anzulegen. Wie man Komponenten zu einem späteren Zeitpunkt anlegen kann, kann man in den Repeater-Klassen ansehen. Aber es geht wesentlich einfacher. Nach dem Erstellen einer Komponente wird als nächstes (für den Fall,dass die Komponente dargestellt wird) onBeforeRender() aufgerufen. Wir können die fehlenden Komponenten in diesem Methodenaufruf erstellen. Wir müssen nur darauf achten, dass diese Initialisierung nur einmal durchgeführt wird. Am besten verpacken wir das ganze in eine eigene Klasse.

package de.wicketpraxis.web.blog.pages.questions.lazy;
 
import org.apache.wicket.markup.html.panel.Panel;
 
public abstract class AbstractLazyPanel extends Panel
{
  boolean _lazyInitCalled;
 
  public AbstractLazyPanel(String id)
  {
    super(id);
  }
 
  @Override
  protected void onBeforeRender()
  {
    if (!_lazyInitCalled)
    {
      _lazyInitCalled=true;
      lazyInit();
    }
    super.onBeforeRender();
  }
 
  protected abstract void lazyInit();
}

Eigene Komponenten werden dann von dieser Klasse abgeleitet. Dieser Umbau hat keine Veränderung des Markup zur Folge, da keinerlei Hilfskomponenten eingefügt wurden.

package de.wicketpraxis.web.blog.pages.questions.lazy;
 
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.model.Model;
 
public class TestPanel extends AbstractLazyPanel
{
  public TestPanel(String id)
  {
    super(id);
  }
 
  @Override
  protected void lazyInit()
  {
    add(new Label("label",Model.of("Label")));
    add(new SimplePanel("panel"));
  }
}


  <span wicket:id="label"></span>
  <br>
  id="panel"></wicket:container>
</wicket:panel>

Wie man sieht, lässt sich die neuen Klasse sehr einfach als Ersatz für die Panel-Klasse benutzen. Vielleicht ist dieser Ansatz ausbaufähig, so dass man durch eine verspätete Initialisierung auch die Probleme rund um TransparentResolver umgehen kann.

Share and Enjoy:

Andere Beiträge

20. Januar 2010 -- Wicket – No TransparentResolver
15. Juli 2010 -- Wicket – Flexibilität mit Factories
14. April 2010 -- Wicket Eclipse Plugin – qwickie

Wicket – lose Koppelung von Komponenten

michael — Tue, 05 Jan 2010 08:02:40 +0000

Auch bei Webanwendungen entstehen schnell komplexe Oberflächen. Es ist nur eine Frage der Zeit, bis man Komponenten, die miteinander interagieren sollen, gegenseitig bekannt macht. Diese Vorgehensweise ist limitiert und außerdem sehr aufwendig. Wie ich bereits im Buch beschrieben habe, kann man die Koppelung von Komponenten aufweichen, die per Ajax neu gezeichnet werden müssen. Dabei ist es zu kurz gedacht, dass man die Entkoppelung von Komponenten nur aus diesem Grund forciert.

Der Unterschied zwischen einem normalen Request und einem Ajax-Request liegt darin, dass bei einem Ajax-Request nur Teile der Seite neu gerendert werden. Dazu müssen die Komponenten markiert werden, die in der Zielseite ersetzt werden sollen. Wenn es sich um einen normalen Request handelt, ist das nicht notwendig, da die ganze Seite und damit alle Komponenten neu gerendert werden.

Solange sich alle Aktionen auf die Änderungen von Daten beziehen, die dann entweder per Ajax neu dargestellt werden oder beim Darstellen der ganzen Seite automatisch angezeigt werden, besteht eigentlich kein Grund, mehr Aufwand in das Entkoppeln von Komponenten zu stecken. Doch oft ist das Ändern der Daten nicht trivial, der Code verteilt sich unwillkürlich auf verschiedene Komponenten.

Um dieser Entwicklung entgegen zu wirken, erweitert man das Event-Konzept einfach auch auf normale Requests. Im folgenden Code werden daher alle notwendigen Klassen aufgeführt. Die im Buch verwendeten Klassen können durch diese ersetzt werden.

package de.wicketpraxis.web.blog.pages.questions.events;
 
public interface EventListenerInterface
{
  public void notifyAjaxEvent(AbstractEvent event);
}

Das EventListenerInterface muss jede Komponente implementieren, dass auf Events reagieren muss.

package de.wicketpraxis.web.blog.pages.questions.events;
 
import org.apache.wicket.Component;
import org.apache.wicket.Page;
import org.apache.wicket.Component.IVisitor;
import org.apache.wicket.ajax.AjaxRequestTarget;
 
public class AbstractEvent
{
  Component _source;
  AjaxRequestTarget _requestTarget;
 
  protected AbstractEvent(Component source,AjaxRequestTarget requestTarget)
  {
    _source=source;
    _requestTarget=requestTarget;
  }
 
  public Component getSource()
  {
    return _source;
  }
 
  public void fire()
  {
    Page page = _source.getPage();
    if (page instanceof EventListenerInterface)
    {
      ((EventListenerInterface) page).notifyAjaxEvent(this);
    }
    page.visitChildren(EventListenerInterface.class, new AjaxEventVisitor(this));
  }
 
  public void update(Component component)
  {
    if (_requestTarget!=null) _requestTarget.addComponent(component);
  }
 
  protected static class AjaxEventVisitor implements IVisitor<Component>
  {
    AbstractEvent _event;
 
    protected AjaxEventVisitor(AbstractEvent event)
    {
      _event=event;
    }
 
    public Object component(Component component)
    {
      ((EventListenerInterface) component).notifyAjaxEvent(_event);
      return IVisitor.CONTINUE_TRAVERSAL;
    }
  }
}

Die Eventklasse wurde dahingehend erweitert, dass jetzt auch für die Seite geprüft wird, ob das EventListernerInterface implementiert wurde. Ob Ajax benutzt wurde oder nicht, wird in der update()-Methode überprüft, so dass man diese Prüfung nicht mehr selbst vornehmen muss.

package de.wicketpraxis.web.blog.pages.questions.events;
 
import org.apache.wicket.Component;
import org.apache.wicket.ajax.AjaxRequestTarget;
 
public class ChangeEvent extends AbstractEvent
{
  int _change;
 
  protected ChangeEvent(Component source, AjaxRequestTarget requestTarget, int change)
  {
    super(source, requestTarget);
 
    _change=change;
  }
 
  public int getChange()
  {
    return _change;
  }
}

Der ChangeEvent wurde abgeleitet und um eine Information erweitert. In der folgenden Komponente wird diese Information ausgewertet:

package de.wicketpraxis.web.blog.pages.questions.events;
 
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.model.IModel;
 
public class CounterPanel extends Panel implements EventListenerInterface
{
  IModel<Integer> _counter;
 
  public CounterPanel(String id,IModel<Integer> counter)
  {
    super(id);
 
    setOutputMarkupId(true);
 
    _counter=counter;
 
    add(new Label("counter",_counter));
  }
 
  public void notifyAjaxEvent(AbstractEvent event)
  {
    if (event instanceof ChangeEvent)
    {
      int change = ((ChangeEvent) event).getChange();
      Integer cur = _counter.getObject();
 
      info("Aktuell: "+cur+" Change: "+change);
 
      _counter.setObject(cur+change);
      event.update(this);
    }
  }
}

Man beachte, dass für die Komponente setOutputMarkupId() aufgerufen wird, da diese Komponente evtl. per Ajax aktualisiert werden kann.


  <span wicket:id="counter"></span>
</wicket:panel>

Jetzt benötigen wir noch eine Komponente, die diesen Event auslöst:

package de.wicketpraxis.web.blog.pages.questions.events;
 
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.model.IModel;
 
public class ActionPanel extends Panel
{
  public ActionPanel(String id,IModel<Integer> change)
  {
    super(id);
 
    AjaxFallbackLink<Integer> link = new AjaxFallbackLink<Integer>("link",change)
    {
      @Override
      public void onClick(AjaxRequestTarget target)
      {
        new ChangeEvent(ActionPanel.this,target,getModelObject()).fire();
      }
    };
    link.add(new Label("change",change));
    add(link);
  }
}


  <a wicket:id="link"><span wicket:id="change"></span></a>
</wicket:panel>

Nachdem wir alle Komponten erstell habe, benutzen wir sie in einer Anwendung:

package de.wicketpraxis.web.blog.pages.questions.events;
 
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.Model;
 
public class EventPage extends WebPage
{
  public EventPage()
  {
    add(new EventFeedbackPanel("feedback"));
 
    add(new ActionPanel("changeAdd1",Model.of(1)));
    add(new ActionPanel("changeSub1",Model.of(-1)));
 
    add(new CounterPanel("counter",Model.of(5)));
  }
 
  static class EventFeedbackPanel extends FeedbackPanel implements EventListenerInterface
  {
    public EventFeedbackPanel(String id)
    {
      super(id);
 
      setOutputMarkupId(true);
    }
 
    public void notifyAjaxEvent(AbstractEvent event)
    {
      event.update(this);
    }
  }
}

Wie man sieht, habe ich auch ein FeedbackPanel erstellt, dass auf Events (und in diesem Fall jedes) reagiert.

<html>
  <head>
    <title>EventPage</title>
  </head>
  <body>
    <div wicket:id="feedback"></div>
 
    <wicket:container wicket:id="changeAdd1"></wicket:container>
    <wicket:container wicket:id="changeSub1"></wicket:container>
 
    <div wicket:id="counter"></div>
  </body>
</html>

Wenn Komponenten per Ajax aktualisiert werden müssen, funktioniert das nur, wenn es auch ein Html-Tag mit der passenden ID gibt, dass per Javascript gefunden und ersetzt werden kann. Daher muss man die Komponente dann an ein Html-Tag binden, die Einbettung über wicket:container funktioniert nicht.

Betätigt man nun einen der Links in der AktionPanel-Komponente, dann wird der Zähler in der CounterPanel-Komponenten angepasst und eine entsprechende Meldung im FeedbackPanel angezeigt. Wenn man nun das CounterPanel einfach ausbaut, passiert nichts. Das zeigt zum einen, dass die Komponenten wirklich unabhängig voneinander sind, zum anderen aber auch, welches Risiko man eingeht: es kann vorkommen, dass Events nicht verarbeitet werden.

Dieses Beispiel veranschaulicht, wie einfach man Komponenten entkoppeln kann. Doch dieses Beispiel ist nur eine einfache Anwendung. Wie weit man diese Vorgehensweise in der Praxis treiben kann, möchte ich in ein paar Sichtpunkten erwähnen:

Anwendung der Möglichkeiten von Vererbung auf Events
Prüfung, ob ein Event einen Empfänger erreicht hat
Kaskadierung von Events (wenn Event A eintrifft, wird Event B ausgelöst)
Mehr als ein Sender und mehr als einen Empfänger für Events
Ein Event kann mit und ohne Ajax ausgelöst werden, ohne dass der Code auf Empfängerseite angepasst werden muss.

Ich hoffe, dass dient als Anregung oder Vorlage. Komplexen Oberflächen mit Wicket steht nun nichts mehr im Weg.

Share and Enjoy:

Andere Beiträge

15. Juli 2010 -- Wicket – Flexibilität mit Factories
16. Oktober 2009 -- Wicket Komponentenübersicht
14. April 2010 -- Wicket Eclipse Plugin – qwickie

Wicket nicht nur für Einsteiger

michael — Wed, 11 Nov 2009 08:03:43 +0000

Ich durfte an einem Projekt teilhaben, in dem für eine neu zu erstellende Anwendung Wicket eingesetzt wurde. Am Anfang wurde das Projekt entsprechend der Anforderungen aufgesetzt (Maven, Hibernate, Spring, Wicket) und der Rahmen der Anwendung geschaffen (Konfiguration der Datenbank, Unittests, etc.). Nach einer doch recht kurzen Einführung in Wicket wurde die Anwendung ohne fremde Hilfe (wenn man mal Google mal ausklammert) entwickelt und mit immer mehr Funktionen angereichert. Gestern habe ich mir den aktuellen Stand angesehen und musste feststellen, dass entgegen meinen Erwartungen eine recht vernünftige Anwendung entstanden ist.

Warum habe ich das so nicht erwartet?

In dem Projekt war bisher wenig bis kein Wissen über Java und die benutzten Frameworks vorhanden. In der kurzen Einführung konnten weder die Sprache, noch die verwendeten Technologien ausführlich genug erklärt werden. Das bedeutet normalerweise, dass die Lösungen, die bei solchen Unterfangen entstehen, verschiedenste Defizite aufweisen. Neben der Tatsache, dass die Anwendung funktioniert (sicher gibt es noch irgendwo ein paar Fehler, aber wo gibt es die nicht), ist die Anwendung auch noch in einer ausreichend guten Verfassung, so dass die Struktur verstanden werden konnte und die Anpassungen, die wir durchgeführt haben, nicht dazu führten, dass etwas nicht mehr funktionierte.

Gründe

Ein nicht unwesentlichen Anteil daran, dass das Projekt besser als erwartet funktioniert hat, trägt sicherlich Wicket als Framework. Wenn man die Hürde genommen hat, die das Thema Modelle darstellt, ist der Rest recht offensichtlich. Eigene Komponenten werden erstellt, weil es a) sehr einfach ist und b) (viel entscheidender) man als Entwickler automatisch davon profitiert. Die Übersichtlichkeit der Anwendung entsteht auf diese Weise automatisch.

Fazit

Das eine Anwendung funktioniert, ist mindestens ein Maßstab zur Bewertung. Diese Anforderung ist gerade bei Webanwendungen nicht einfach zu erreichen. In Anbetracht der eher schlechten Voraussetzungen muss man das Ergebnis als gelungen bezeichnen. Da ich gebeten wurde, meine Einschätzung zu diesem Projekt abzugeben, freut es nicht nur mich, sondern sicher auch das Team, dass ich positiv überrascht bin.

Mit welcher anderen Technologie wäre dieses Projekt ähnlich gut verlaufen?

Share and Enjoy:

Andere Beiträge

15. Juli 2010 -- Wicket – Flexibilität mit Factories
14. April 2010 -- Wicket Eclipse Plugin – qwickie
9. April 2010 -- Wicket – AbstractEvent Update

PropertyModel – einfach ist nicht immer gut

michael — Wed, 04 Nov 2009 07:17:20 +0000

Ich bin kürzlich über ein Stück Code gestolpert, der mich zum nachdenken brachte. Um zu illustrieren, welcher Umstand dafür verantwortlich war, benötige ich diesemal am schon Anfang ein paar Zeilen Code. Die folgende Hilfsklasse dient nur dazu, bei dem einzig möglichen Methodenaufruf eine Liste von Daten zu erzeugen:

package de.wicketpraxis.web.blog.pages.migration.model.property;
 
import java.io.Serializable;
import java.util.Arrays;
import java.util.List;
 
public class Generator implements Serializable
{
  public List<String> findAll()
  {
    return Arrays.asList("fun","with","wicket");
  }
}

Der Generator dient hier als Platzhalter für eine wie auch immer gelagerte Datenschicht.

package de.wicketpraxis.web.blog.pages.migration.model.property;
 
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.ListView;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.LoadableDetachableModel;
import org.apache.wicket.model.Model;
import org.apache.wicket.model.PropertyModel;
 
import de.wicketpraxis.wicket.model.Models;
import de.wicketpraxis.wicket.model.transformation.Function1;
 
public class UseOrNotUsePropertyModelPage extends WebPage
{
  public UseOrNotUsePropertyModelPage()
  {
    final Generator gen=new Generator();
 
    IModel<List<String>> model = new LoadableDetachableModel<List<String>>()
    {
      protected List<String> load()
      {
        return gen.findAll();
      };
    };
 
    model=new PropertyModel<List<String>>(gen,"findAll");
 
    add(new ListView<String>("list",model)
    {
      @Override
      protected void populateItem(ListItem<String> item)
      {
        item.add(new Label("value",item.getModel()));
      }
    });
  }
}

Da es nicht meine Art ist, unvollständigen Code abzubilden, kommt auch hier erst das Markup und dann die Erklärung:

<html>
  <head>
    <title>PropertyModel Usage Page</title>
  </head>
  <body>
    <h1>Liste</h1>
    <ul>
      <li wicket:id="list"><span wicket:id="value"></span></li>
    </ul>
  </body>
</html>

Was ist an diesem Beispiel bemerkenswert?

Am Anfang erzeuge ich ein Model über eine LoadableDetachableModel-Implementierung, die die Daten aus dem Methodenaufruf zurück gibt. Das ist nichts neues und wurde bereits oft behandelt. Diese Model-Instanz wird in der folgenden Zeile mit einer PropertyModel-Instanz überschrieben. Es ist unstrittig, dass dieser Ansatz funktioniert. Die Methode wird per Reflection aufgerufen und die Werte werden per getObject() zurückgeliefert. Doch wo liegt das Problem?

Refactoring

Die Zeile Code, die man erhält, wenn man das PropertyModel benutzt und die Methode aufzurufen ist angenehm kurz. Aber diese Kürze gibt es nicht umsonst, sondern man muss dafür zahlen. In Bezug auf das Thema Refactoring sogar zwei mal. Das erste Problem ist offensichtlich: Wenn sich der Methodenname ändert (oder Parameter hinzukommen) wird der Aufruf per Reflection nicht mehr funktionierten (oder sogar eine falsche Methode aufrufen), und man erhält zur Laufzeit eine Fehlermeldung.

Der zweite Punkt ist weniger offensichtlich, aber vielleicht noch schwer wiegender, weil zur Laufzeit der Fehler an einer anderen Stelle zu Tage tritt: Der Rückgabewert der Methode wird angepasst. Der Fehler würde in unserem Fall dann vermutlich nur in der Darstellung der ListView auftreten, so dass statt “fun with wicket” möglicherweise “SomeData@65b778 SomeData@32ac12″ angezeigt wird. Es kommt also noch nicht mal zu einem Laufzeitfehler.

Performance

In einem anderen Bereich (der in unserem Beispiel nebensächlich ist) funktioniert die PropertyModel-Variante nicht wie erwartet. Wenn die Methode getObject() aufgerufen wird, wird immer die entsprechende Methode per Reflection aufgerufen. Das bedeutet, die Ergebnisse werden nicht wie beim LoadableDetachedModel zwischengespeichert. Würde ich das Model an zwei ListView-Komponenten binden, würde die Liste zweimal erzeugt werden. Je nach Aufwand der Erzeugung ist das ein eher unerwünschtes Ergebnis. Außerdem kann es natürlich dazu kommen, dass sich die jeweiligen Rückgabewerte unterscheiden, so dass der Nutzer im Zweifel inkonsistente Daten angezeigt bekommt.

Das PropertyModel ist nützlich

Man sollte nach dem Lesen der Zeilen die Verwendung des PropertyModel nicht verbieten, denn Aufwand und Nutzen sind für die Entstehung dieser Model-Klasse verantwortlich. Um die Eingaben aus einem Formularfeld in einem Attribut einer JavaBean zu speichern sollte man das PropertyModel einsetzen, weil der Mehraufwand für eine typsichere (und damit durch normale Refactoring-Operationen greifbare) Variante enorm hoch ist. Ich würde mir wünschen, das Java Sprachmittel bereitstellt, die es ermöglicht, Methoden nicht nur per Reflection zu ermitteln, so dass man gerade für diesen Fall kompakten und trotzdem typsicheren Code schreiben kann. Bis dahin sollte man diese Model-Klasse überlegt verwenden, dann kann eigentlich gar nicht soviel schief gehen.

Share and Enjoy:

Andere Beiträge

28. Oktober 2009 -- Wicket Model Transformation
16. Oktober 2009 -- Wicket Komponentenübersicht
22. September 2009 -- Migration zu Wicket: Model

Wicket Model Transformation

michael — Wed, 28 Oct 2009 06:11:48 +0000

Eine Liste von Ergebnissen aus einer Tabelle in der Datenbank zu laden und über ein Model zur Verfügung zu stellen, ist eine recht einfache Angelegenheit. Wicket sorgt dafür, dass die Liste kein zweites mal geladen wird, nur weil das Model durch eine zweite Komponente dargestellt wird. Wenn man z.B. so triviale Dinge wie die Summe aller angezeigten Einträge ermitteln möchte, empfiehlt es sich, auf die bereits geladenen Daten aus dem Model zurückzugreifen. Für diesen Zweck kann man auf eine spezialisierte Model-Klasse zurückgreifen, die sich darum kümmert, das die detach()-Methode auch für alle referenzierten Modelle aufgerufen wird. Der Ansatz ist recht einfach, aber es geht vielleicht noch ein wenig eleganter.

Die Transformation

Als erstes definieren wir Klassen, die für die Transformation sorgen. Da in unserem Beispiel nicht nur ein Model, sondern auch zwei oder drei Model-Referenzen benutzt werden und damit bis zu drei Parametern übergeben werden können, müssen wir auch drei unterschiedliche Schnittstellen definieren:

package de.wicketpraxis.wicket.model.transformation;
 
import java.io.Serializable;
 
public interface Function1<T,M1> extends Serializable
{
  public T apply(M1 value);
}

package de.wicketpraxis.wicket.model.transformation;
 
import java.io.Serializable;
 
public interface Function2<T,M1,M2> extends Serializable
{
  public T apply(M1 value,M2 value2);
}

package de.wicketpraxis.wicket.model.transformation;
 
import java.io.Serializable;
 
public interface Function3<T,M1,M2,M3> extends Serializable
{
  public T apply(M1 value,M2 value2, M3 value3);
}

Da die verschiedenen Modelle auch verschiedene Daten bereitstellen können, kann jeder Parameter einen eigenen Typ annehmen. Jetzt benötigen wir ein Model, dass die Daten der referenzierten Modelle lädt und der Funktion übergibt und sich das Ergebnis bis zum Aufruf von detach() merkt.

package de.wicketpraxis.wicket.model.transformation;
 
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.LoadableDetachableModel;
 
public abstract class Transformator<T> extends LoadableDetachableModel<T>
{
  IModel[] _subModels;
 
  protected Transformator(IModel ... subModels)
  {
    _subModels=subModels;
  }
 
  @Override
  protected void onDetach()
  {
    for (IModel m : _subModels)
    {
      m.detach();
    }
  }
 
  public static class Model1<T,M1> extends Transformator<T>
  {
    IModel<M1> _m1;
    Function1<T, M1> _function;
 
    public Model1(IModel<M1> m1, Function1<T, M1> function)
    {
      super(m1);
 
      _m1=m1;
      _function=function;
    }
 
    @Override
    protected T load()
    {
      return _function.apply(_m1.getObject());
    }
  }
 
  public static class Model2<T,M1,M2> extends Transformator<T>
  {
    IModel<M1> _m1;
    IModel<M2> _m2;
    Function2<T, M1, M2> _function;
 
    public Model2(IModel<M1> m1, IModel<M2> m2, Function2<T, M1, M2> function)
    {
      super(m1,m2);
 
      _m1=m1;
      _m2=m2;
      _function=function;
    }
 
    @Override
    protected T load()
    {
      return _function.apply(_m1.getObject(),_m2.getObject());
    }
  }
 
  public static class Model3<T,M1,M2,M3> extends Transformator<T>
  {
    IModel<M1> _m1;
    IModel<M2> _m2;
    IModel<M3> _m3;
    Function3<T, M1, M2, M3> _function;
 
    public Model3(IModel<M1> m1, IModel<M2> m2, IModel<M3> m3, Function3<T, M1, M2, M3> function)
    {
      super(m1,m2,m3);
 
      _m1=m1;
      _m2=m2;
      _m3=m3;
      _function=function;
    }
 
    @Override
    protected T load()
    {
      return _function.apply(_m1.getObject(),_m2.getObject(),_m3.getObject());
    }
  }
}

Das war jetzt ein größerer Block, der aber eigentlich nur aus 3 fast gleichen Klassendefinitionen bestand, die leider nicht viel besser zusammenzuführen sind. Wichtig ist dabei die Übergabe aller Model-Referenzen an die Basisklasse, die sich in der onDetach()-Methode (die von der detach()-Methode nur aufgerufen wird, wenn für das Model noch nicht detach() aufgerufen wurde) um das Aufrufen der detach()-Methode dieser Modelle kümmert.

Noch ist dieses ganze Konstrukt nicht viel besser handhabbar als die bisher favorisierte Lösung. Wir benötigen daher noch ein paar Hilfsklassen.

package de.wicketpraxis.wicket.model.transformation;
 
import org.apache.wicket.model.IModel;
 
public abstract class ModelSet
{
  public static class Set1<M1>
  {
    IModel<M1> _m1;
 
    public Set1(IModel<M1> m1)
    {
      _m1=m1;
    }
 
    public <T> IModel<T> apply(Function1<T, M1> function)
    {
      return new Transformator.Model1<T, M1>(_m1,function);
    }
  }
 
  public static class Set2<M1,M2>
  {
    IModel<M1> _m1;
    IModel<M2> _m2;
 
    public Set2(IModel<M1> m1,IModel<M2> m2)
    {
      _m1=m1;
      _m2=m2;
    }
 
    public <T> IModel<T> apply(Function2<T, M1, M2> function)
    {
      return new Transformator.Model2<T, M1, M2>(_m1,_m2,function);
    }
  }
 
  public static class Set3<M1,M2,M3>
  {
    IModel<M1> _m1;
    IModel<M2> _m2;
    IModel<M3> _m3;
 
    public Set3(IModel<M1> m1,IModel<M2> m2,IModel<M3> m3)
    {
      _m1=m1;
      _m2=m2;
      _m3=m3;
    }
 
    public <T> IModel<T> apply(Function3<T, M1, M2, M3> function)
    {
      return new Transformator.Model3<T, M1, M2, M3>(_m1,_m2,_m3, function);
    }
  }
}

Wir man erkennen kann, bestehen diese Klassen auch wieder aus drei Kopien, die mehr oder weniger die selbe Funktion, nur andere Parameter haben. Bis jetzt muss das Bild noch verschwommen sein, mit dem letzten Baustein sollte es sich klären.

package de.wicketpraxis.wicket.model;
 
import org.apache.wicket.model.IModel;
 
import de.wicketpraxis.wicket.model.transformation.ModelSet;
 
public abstract class Models
{
  public static <T,M1> ModelSet.Set1<M1> on(IModel<M1> model)
  {
    return new ModelSet.Set1<M1>(model);
  }
  public static <T,M1,M2> ModelSet.Set2<M1,M2> on(IModel<M1> model,IModel<M2> model2)
  {
    return new ModelSet.Set2<M1,M2>(model,model2);
  }
  public static <T,M1,M2,M3> ModelSet.Set3<M1,M2,M3> on(IModel<M1> model,IModel<M2> model2,IModel<M3> model3)
  {
    return new ModelSet.Set3<M1,M2,M3>(model,model2,model3);
  }
}

Fertig. Nun, vielleicht noch nicht ganz. Wir haben eine ganze Reihe von Klassen, eine ganze Menge Code, um die selben Anforderungen zu Erfüllen, wie mit dem im ersten Moment sehr viel einfacher gehaltenen Model-Ansatz aus dem anderen Artikel? Sehen wir uns daher das ganze in der Anwendung an.

Beispiel

In dem folgenden Beispiel benötigen wir ein Model, das eine Zufallszahl bereitstellt:

package de.wicketpraxis.web.blog.pages.migration.model.transformation;
 
import org.apache.wicket.model.LoadableDetachableModel;
 
public class RandomNumberModel extends LoadableDetachableModel<Double>
{
  @Override
  protected Double load()
  {
    return Math.random();
  }
}

Diese Modell benutzen wir auf einer Seite als Datenquelle:

package de.wicketpraxis.web.blog.pages.migration.model.transformation;
 
import org.apache.wicket.ajax.AjaxSelfUpdatingTimerBehavior;
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.model.IModel;
import org.apache.wicket.util.time.Duration;
 
import de.wicketpraxis.wicket.model.Models;
import de.wicketpraxis.wicket.model.transformation.Function1;
import de.wicketpraxis.wicket.model.transformation.Function2;
 
public class TransformationPage extends WebPage
{
  public TransformationPage()
  {
    IModel<Double> randModel1=new RandomNumberModel();
    IModel<Double> randModel2=new RandomNumberModel();
 
    IModel<Double> diffResult = Models.on(randModel1, randModel2)
      .apply(new Function2<Double, Double, Double>()
    {
      public Double apply(Double value, Double value2)
      {
        return value-value2;
      }
    });
 
    IModel<Integer> scaleResult = Models.on(randModel1)
      .apply(new Function1<Integer, Double>()
    {
      public Integer apply(Double value)
      {
        return (int)(value*100);
      }
    });
 
    WebMarkupContainer ajaxUpdate=new WebMarkupContainer("ajaxUpdate");
    ajaxUpdate.setOutputMarkupId(true);
    ajaxUpdate.add(new AjaxSelfUpdatingTimerBehavior(Duration.seconds(1)));
 
    ajaxUpdate.add(new Label("rand1",randModel1));
    ajaxUpdate.add(new Label("rand2",randModel2));
    ajaxUpdate.add(new Label("diffResult",diffResult));
    ajaxUpdate.add(new Label("scaleResult",scaleResult));
 
    add(ajaxUpdate);
  }
}

In diesem Beispiel erstellen wir zwei unabhängige Modelle für jeweils zwei Zufallszahlen. Diese werden über zwei Funktionsinstanzen manipuliert und als Model bereitgestellt. Dabei ist zu beachten, dass nicht das Ergebnis als Model bereitgestellt wird, sondern dass ein Model erzeugt wird, bei dem beim ersten Aufruf von getObject() die load()-Methode des LoadableDetachedModel aufgerufen wird, dass dann dort die Daten aus den referenzierten Modellen ermittelt und durch die Funktion transformiert. Das Ergebnis wird bis zum Aufruf von detach() (durch die angebundene Komponente) gepuffert.

Damit die Zufallszahlen immer wieder erzeugt werden, lassen wir die Anzeige sich per Ajax selbsttätig aktualisieren.

<html>
  <head>
    <title>Transformation Page</title>
  </head>
  <body>
    <h1>Zufallszahlen</h1>
    <div wicket:id="ajaxUpdate">
      <table>
        <tr>
          <td>Nummer 1</td><td><span wicket:id="rand1"></span></td>
        </tr>
        <tr>
          <td>Nummer 2</td><td><span wicket:id="rand2"></span></td>
        </tr>
        <tr>
          <td>Number 1*100</td><td><span wicket:id="scaleResult"></span></td>
        </tr>
        <tr>
          <td>Number 1-Nummer 2</td><td><span wicket:id="diffResult"></span></td>
        </tr>
      </table>
    </div>
  </body>
</html>

Fazit

Wo liegt jetzt der Vorteil? Zum einen sind die Implementierungen einfacher, da laut Schnittstellendefinition nur eine Methode implementiert werden muss. Zum anderen muss man nicht die benutzten Model-Klassen kennen, die diese Transformationen durchführen. Die Lesbarkeit ist wesentlich besser, weil aus dem Code abgeleitet werden kann, was da in etwa passiert.

Ist das der Weisheit letzter Schluss? Vermutlich nicht. Anregungen sind daher willkommen.

Share and Enjoy:

Andere Beiträge

22. September 2009 -- Migration zu Wicket: Model
3. Januar 2009 -- Modell-Referenzen
4. November 2009 -- PropertyModel – einfach ist nicht immer gut

Wicket Tipps: Markup

michael — Tue, 27 Oct 2009 07:05:16 +0000

Ich benutze für alle Projekte Maven. Der eine oder andere mag mit Maven auf dem Kriegsfuß stehen (was ich zwar nicht verstehe, aber akzeptiere). Bisher war ich (und an anderer Stelle war es auch nicht notwendig, darüber nachzudenken) für eine saubere Trennung von Code und Resourcen. Das bedeutet z.B. das der Code einer Wicket-Komponente z.B. im Pfad src/main/java/de/wicketpraxis/ zu finden ist und das Markup in src/main/resources/de/wicketpraxis.

Das Projekt wächst und gedeiht und es entstehen unzählige Komponenten (ein Zeichen dafür, dass man mit Wicket sehr sehr einfach eigene Komponenten erstellen kann). Im Laufe der Zeit hat es sich als unpraktisch herausgestellt, in der IDE immer zwischen diesen beiden Verzeichnissen zu wechseln. Auch beim Refactoring kann es sich als lästig erweisen, weil man an zwei Stellen die selbe Operation anwenden muss (zumindest in Eclipse).

Ich habe daher alle Projekte umgestellt und kann nun die Markup-Dateien in das selbe Verzeichnis/Package wie die Komponente legen. Die Angst, dass die Übersichtlichkeit leidet, hat sich als unbegründet erwiesen, die Produktivität ist spürbar besser. Folgende Anpassung muss man daher in einem Projekt vornehmen. In der pom.xml ist folgender Block einzufügen:

  >
...
    >
      >
        >src/main/resources>
      >
      >
        >src/main/java>
        >
          >**/*.java>
        >
      >
    >
...
  >

Wenn man nun die Anwendung über Jetty aus dem Projekt heraus starten möchte, empfiehlt sich ein Ansatz, den ich bereits im folgenden Beitrag erwähnt habe: Wicket Resourcen mit Jetty nachladen. Allerdings müssen wir dazu den angepassten ResourceStreamLocator entsprechend erweitern. Am besten wir schreiben eine neue Klasse:

package de.wicketpraxis.wicket.util.resource;
 
import org.apache.wicket.util.file.File;
import org.apache.wicket.util.resource.FileResourceStream;
import org.apache.wicket.util.resource.IResourceStream;
import org.apache.wicket.util.resource.locator.ResourceStreamLocator;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
 
public class MavenDevResourceAndSourceStreamLocator extends ResourceStreamLocator
{
  private static final Logger _logger = LoggerFactory.getLogger(MavenDevResourceAndSourceStreamLocator.class);
 
  final static String MAVEN_RESOURCE_PATH="src/main/resources/";
  final static String MAVEN_JAVASOURCE_PATH="src/main/java/";
 
  @Override
  public IResourceStream locate(final Class clazz, final String path)
  {
    IResourceStream located=getFileSysResourceStream(MAVEN_RESOURCE_PATH,path);
    if (located==null)
    {
      located=getFileSysResourceStream(MAVEN_JAVASOURCE_PATH,path);
    }
    if (located != null)
    {
      if (_logger.isInfoEnabled()) _logger.info("Locate: " + clazz + " in " + path+" -> "+located);
      return located;
    }
    located=super.locate(clazz, path);
    if (_logger.isInfoEnabled()) _logger.info("Locate: " + clazz + " in " + path+" -> "+located+"(Fallback)");    
    return located;
  }
 
  private static IResourceStream getFileSysResourceStream(String prefix, String path)
  {
    File f=new File(prefix+path);
    if ((f.exists()) && (f.isFile()))
    {
      return new FileResourceStream(f);
    }
    return null;
  }
}

Die Einbindung funktioniert wie beim letzten Mal:

if (DEVELOPMENT.equalsIgnoreCase(configurationType))
{
  getResourceSettings().setResourceStreamLocator(new MavenDevResourceAndSourceStreamLocator());
}

Jetzt sollte man (wenn alles andere entsprechend vorbereitet ist) mit mvn jetty:run -Dwicket.configuration=development Jetty aus dem Projekt heraus starten können. Sobald man Änderungen am Markup vorgenommen hat, werden diese neu geladen.

Share and Enjoy:

Andere Beiträge

31. Dezember 2008 -- Wicket Resourcen mit Jetty nachladen
13. Januar 2010 -- Wicket und Eclipse
15. Juli 2010 -- Wicket – Flexibilität mit Factories

Wicket “stateless” – keine einfache Herausforderung

michael — Thu, 30 Jul 2009 10:18:57 +0000

Wie in den Kommentaren der letzten Tage sichtbar wurde, eignet sich Wicket nicht “ungeschminkt” für Webseiten, die ihre Zustandsinformationen klassisch in URL-Parametern ablegen. In meinem Buch beschreibe ich eine einfache Variante, die bereits zum Ziel führen kann.

Die Herausforderung liegt darin, dass man von den Vorteilen, die Wicket mitbringt nicht all zu viele einbüßt. Daher werde ich mich in den nächsten Tagen mal damit beschäftigen, wie man mit möglichst wenig Aufwand Anwendungen realisieren kann, die auf der einen Seite URL-Parameter benutzen, auf der anderen Seite aber nicht auf saubere Komponenten verzichten müssen.

Auch wenn es schwer ist, sich von der Herangehensweise wie man sie mit JSP,PHP,… gewöhnt ist, zu lösen, erschließt man das volle Potential von Wicket erst dann, wenn man sich auf den “Wicket-Pfad” begibt. Der einzige Aspekt, der es notwendig macht, sich mit der Frage von URL-Parametern zu beschäftigen, ist die Suchmaschinentauglichkeit der Anwendung. Da muss man allerdings auch überlegen, ob man nicht einen Sitemap generiert, die alle gewünschten Inhalte ansteuerbar macht, so dass man nicht gezwungen ist, eine SEO-taugliche Navigation aufzusetzen.

Wicket ist ganz sicher nicht für jede Anforderung geeignet. Unbestritten. Die Alternativen sind IMHO allerdings auch nicht zufriedenstellender.

Share and Enjoy:

Andere Beiträge

4. August 2009 -- Web 1.0 mit Wicket – Seitenparameter und Links
21. Juli 2009 -- Wicket saved the day
15. Juli 2010 -- Wicket – Flexibilität mit Factories

Wicket und Scala – der Rückweg ist anstrengend

michael — Fri, 19 Jun 2009 07:20:14 +0000

Ich habe mal ein wenig mit Scala rumgespielt und mit den Sprachmöglichkeiten, die Scala bietet, versucht aus einem Java-lastigen Wicket-Beispiel etwas zu machen, was sich wie Scala anfühlt. Zuerst der Java-Code:

package de.flapdoodle.incubator.scalawicket.web.pages;
 
import org.apache.wicket.Component;
import org.apache.wicket.IClusterable;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
import org.apache.wicket.ajax.markup.html.AjaxLink;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.CompoundPropertyModel;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.Model;
import org.apache.wicket.model.PropertyModel;
 
public class StartJava extends WebPage
{
  public StartJava()
  {
    IModel messageModel=Model.of("Huiii");
    final Label label=new Label("message",messageModel);
    label.setOutputMarkupId(true);
 
    add(label);
 
    final Bean bean=new Bean();
    bean.setName("Klaus");
    bean.setAlter(12);
 
    final Component labelName = new Label("name",new PropertyModel(bean,"name")).setOutputMarkupId(true);
    final Component labelAlter = new Label("alter",new PropertyModel(bean,"name")).setOutputMarkupId(true);
    add(labelName);
    add(labelAlter);
 
    final Form form=new Form("form", new CompoundPropertyModel(bean));
    form.add(new TextField("name")).add(new TextField("alter"));
    form.setOutputMarkupId(true);
    add(form);
 
    add(new AjaxFallbackLink("link",messageModel)
    {
      public void onClick(AjaxRequestTarget target) 
      {
        getModel().setObject("Klick");
        bean.setName("Peter");
        target.addComponent(form);
        target.addComponent(label);
        target.addComponent(labelName);
        target.addComponent(labelAlter);
      }
    });
 
    add(new AjaxLink("link2",messageModel)
    {
      @Override
      public void onClick(AjaxRequestTarget target)
      {
        getModel().setObject("Klack");
        bean.setAlter(24);
        target.addComponent(form);
        target.addComponent(label);
        target.addComponent(labelName);
        target.addComponent(labelAlter);
      }
    });
  }
 
  class Bean implements IClusterable
  {
    String _name;
    int _alter;
    public String getName()
    {
      return _name;
    }
    public void setName(String name)
    {
      _name = name;
    }
    public int getAlter()
    {
      return _alter;
    }
    public void setAlter(int alter)
    {
      _alter = alter;
    }
  }
}

.. und nun das ganze in Scala

package de.flapdoodle.incubator.scalawicket.web.pages;
 
import org.apache.wicket.Component;
import org.apache.wicket.IClusterable;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
import org.apache.wicket.ajax.markup.html.AjaxLink;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.CompoundPropertyModel;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.Model;
import org.apache.wicket.model.PropertyModel;
import de.flapdoodle.incubator.scalawicket.web.wicket.WicketHelper._
import scala.reflect.BeanProperty;
 
class Start extends WebPage 
{
  val messageModel=Model.of("Huiii")
  val label=new Label("message",messageModel)
  label.enableAjax
 
  this+=label;
 
  val bean=new Bean
  bean.name="Klaus";
  bean.alter=12;
 
  val labelName = new Label("name",bean model {_.name}).enableAjax
  val labelAlter = new Label("alter",bean model {_.alter}).enableAjax
  this+=labelName
  this+=labelAlter
 
  val form=new Form[Bean]("form", new CompoundPropertyModel[Bean](bean));
  form+=(new TextField("name"),new TextField("alter"))
  form.enableAjax
  this+=form
 
  this+=new AjaxFallbackLink[String]("link",messageModel)
  {
    override def onClick(target: AjaxRequestTarget) = 
    {
      this.model set "Klick"
      bean.name="Peter"
      target.refresh(form,label,labelName,labelAlter)
    }
  };
 
  this+=new AjaxLink("link2",messageModel)
  {
    override def onClick(target: AjaxRequestTarget) =
    {
      this.model set "Klack"
      bean.alter=24
      target.refresh(form,label,labelName,labelAlter)
    }
  };
 
  class Bean extends IClusterable
  {
    @BeanProperty
    var name: String = _;
    @BeanProperty
    var alter: Integer = _;
  }
}

Zuerst zu den offensichtlichen Dingen:

Java: Zeilen=91, Wörter=155, Zeichen=2.567
Scala: Zeilen=69(75%), Wörter=126(81%), Zeichen=1.921(75%)

In diesem Beispiel kann Scala seine Vorteile vielleicht noch nicht richtig ausspielen. Wobei 25% weniger Schreibarbeit (wenn man vernachlässigt, dass ich einmalig etwas Scala-Code schreiben musste, was mir das ermöglicht) für dieses Beispiel vielleicht auch schon eine bemerkenswerte Menge ist.

Spannender ist folgender Umstand: Ich habe den Java-Code aus dem Scala-Code abgeleitet. Wenn ich das Beispiel direkt in Java geschrieben hätte, sähe der Code fast genauso aus. Als ich aber den Scala-Code rückübersetzte, fiel es mir sehr schwer, die ganzen Typ-Definitionen zu schreiben, die abschließende Semikolons zu setzen und Parameter in geschweifte Klammern einzubetten. Auch wenn die Unterstützung für Scala in Eclipse noch einiges Potential hat, kann man a) damit bereits erstaunlich gut arbeiten (wenn man bedenkt, welche interessanten Sprachmöglichkeiten (und damit Schwierigkeiten für eine IDE) Scala bietet).

Meine schönste Zeile Code ist in diesem Beispiel das Erzeugen eines AbstractReadOnlyModel durch den Aufruf von “bean model { _.alter }”, der in diesem Fall das selbe leistet wie ein PropertyModel, nur dass das Attribut nicht erst per Reflection ermittelt wird.

Ich warte eigentlich darauf, dass jemand Wicket nach Scala portiert, denn das Lift-Framework gefällt mir nicht so gut (da wird wieder Code in die Templates verlagert). Jetzt geht es erst einmal weiter mit Java, auch wenn der Rückweg jetzt schon ein beschwerlicher war.

Share and Enjoy:

Andere Beiträge

26. August 2009 -- Scala vs Java
21. Juli 2009 -- Sails – die Scala Version von Rails/Grails
7. Juli 2009 -- Scala kommt