Wicket Kompontenten – Basis

Wicket Komponenten inklusive Extensions

Wicket Modelle

Wicket Behavior

Wicket Listener

Wicket RequestTarget

Andere Beiträge

• No Related Post

Was macht das Plugin?

Mit dem Plugin ist es möglich, durch den Klick auf die Wicket-ID einer Komponente zwischen Java-Klasse und zugehörigen Markup wechseln zu können. Dabei springt der Cursor gleich an die richtige Stelle. Kurz: Das ist genau das, was ich am häufigsten benötige.

Bei der Installation sollte man zwei Dinge beachten: 1. Das Plugin befindet sich wirklich noch in einem sehr frühen Stadium, so dass Fehler auftreten. Man muss also abwägen, ob der Vorteil die Nachteile aufwiegt. 2. Die Hinweise zur Installation und zur Handhabung auf der Seite sollte man beachten.

Diese Plugin sollte man im Auge behalten. Sofern es meine Zeit erlaubt, werde ich versuchen, an diesem Plugin mitzuentwickeln.

Andere Beiträge

• 13. Januar 2010 -- Wicket und Eclipse
• 29. April 2011 -- Wicket – Back Button zuverlässig erkennen
• 24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB

package de.wicketpraxis.web.blog.pages.questions.ajax.modal;
 
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxLink;
import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
import org.apache.wicket.markup.html.panel.Panel;
 
public abstract class AbstractModalClosePanel extends Panel
{
  public AbstractModalClosePanel(ModalWindow modalWindow)
  {
    super(modalWindow.getContentId());
 
    add(new AjaxLink<Void>("link")
    {
      @Override
      public void onClick(AjaxRequestTarget target)
      {
        AbstractModalClosePanel.this.onClick(target);
      }
    });
  }
 
  public abstract void onClick(AjaxRequestTarget target);
}

Die ModalWindow-Komponente kann nur eine andere Komponente anzeigen. Daher ist die Komponenten-ID fest definiert. Daher macht es Sinn, statt einer eigenen ID einfach das ModalWindow, in dem die Komponente angezeigt werden soll als Parameter zu übergeben. Damit diese Komponente auch eine Funktion bereitstellt, fügen wir einen Link hinzu. Wichtig: Wenn man Formulare benutzen möchte, muss man diese bei Anzeige durch ein ModalWindow per Ajax absenden.

Das Markup der Komponente ist wenig überraschend:

<wicket:panel>
  <div>
    Nothing to hide:)
    <a wicket:id="link">Link</a>
  </div>
</wicket:panel>

Die ModalWindow-Komponente unterscheidet sich von anderen Komponenten in einem wesentlichen Punkt. Die Darstellung wird nicht durch ein Markup realisiert, dass man überschreiben könnte. Der Rahmen für das Fenster wird per Javascript erzeugt. Um das Aussehen der Komponente anzupassen müssen wir also etwas tiefer in die Trickkiste greifen.

In diesem Beispiel nehmen wir Veränderungen an verschiedenen Stellen vor. Fangen wir mit den Grafiken für den Rahmen an. Der Einfachheit halber verändere ich nur die Farbwirkung aber nicht die Dimensionen, so dass ich die vorhandenen Grafiken (die man sich aus dem wicket-extension.jar extrahieren kann) nur leicht verändere:

Es gibt zwei Grafiken, wobei es für jede noch eine Version für den InternetExplorer gibt, die auf transparente Schatten verzichtet (der InternetExplorer hat da Schwierigkeiten, ähm.. nicht nur da). Wie man sieht befinden sich die Grafikinformationen für die Ränder, Ecken und Buttons in einer Grafik. Das Stylesheet sorgt dafür, dass an der richtigen Stelle die richtige Grafik eingeblendet wird. Daher müssen wir eine eigene Stylesheet-Datei einbinden, die unsere Anpassungen wiederspiegelt. Auch an dieser Stelle ist es sinnvoll, sich den Inhalt der ModalWindow-eigenen Stylesheet-Datei anzuschauen.

div.wicket-modal div.w_content_3
{
  border:0px;
}
 
div.wicket-modal div.w_caption
{
  background-color: inherit;
}
 
div.wicket-modal a.w_close {  
  top: 3px;
}
 
div.wicket-modal div.custom div.w_left,
div.wicket-modal div.custom div.w_right {
  background-image: url('frame-custom-2-alpha.png'); 
  _background-image: url('frame-custom-2-ie.png');
}
 
 
div.wicket-modal div.custom div.w_top,
div.wicket-modal div.custom div.w_bottom,
div.wicket-modal div.custom div.w_topLeft,
div.wicket-modal div.custom div.w_topRight,
div.wicket-modal div.custom div.w_bottomRight,
div.wicket-modal div.custom div.w_bottomLeft,
div.wicket-modal div.custom a.w_close {
  background-image: url('frame-custom-1-alpha.png'); 
  _background-image: url('frame-custom-1-ie.png');
}

Wie ich bereits weiter oben erwähnt habe, wird das Html für den Rahmen nicht wie üblich sondern per Javascript erzeugt. Da wir auch an dieser Stelle Anpassungen vornehmen wollen, müssen wir die entsprechende Funktion überschreiben:

Wicket.Window.getMarkup = function(idWindow, idClassElement, idCaption, idContent, idTop, idTopLeft, idTopRight, idLeft, idRight, idBottomLeft, idBottomRight, idBottom, idCaptionText, isFrame) {
  var s =
      "<div class=\"wicket-modal\" id=\""+idWindow+"\" style=\"top: 10px; left: 10px; width: 100px;\"><form style='background-color:transparent;padding:0px;margin:0px;border-width:0px;position:static'>"+
      "<div id=\""+idClassElement+"\">"+
        "<div class=\"w_caption\"  id=\""+idCaption+"\">"+
          "<a class=\"w_close\" href=\"#\"></a>"+                 
          "<span id=\""+idCaptionText+"\" class=\"w_captionText\"></span>"+
        "</div>"+
 
        "<div class=\"w_top_1\">"+
 
        "<div class=\"w_topLeft\" id=\""+idTopLeft+"\">"+
        "</div>"+       
 
        "<div class=\"w_topRight\" id=\""+idTopRight+"\">"+
        "</div>"+
 
        "<div class=\"w_top\" id='"+idTop+"'>"+                 
        "</div>"+
 
        "</div>"+
 
        "<div class=\"w_left\" id='"+idLeft+"'>"+
          "<div class=\"w_right_1\">"+
            "<div class=\"w_right\" id='"+idRight+"'>"+
              "<div class=\"w_content_1\" onmousedown=\"if (Wicket.Browser.isSafari()) { event.ignore = true; }  else { Wicket.stopEvent(event); } \">"+                                      
 
                "<div class=\"w_content_2\">"+
                "<div class=\"w_content_3\">"+
                  "<div class=\"w_content\">";
        if (isFrame) {
          if (Wicket.Browser.isIELessThan7() || !Wicket.Browser.isIE()) {                       
            s+= "<iframe src='\/\/:' frameborder=\"0\" id='"+idContent+"' allowtransparency=\"false\" style=\"height: 200px\">"+
                    "</iframe>";
          } else {
            s+= "<iframe src='about:blank' frameborder=\"0\" id='"+idContent+"' allowtransparency=\"false\" style=\"height: 200px\">"+
            "</iframe>";
          }
        } else {
          s+=
                    "<div id='"+idContent+"'></div>";
        }
          s+=             
                  "</div>"+
                "</div>"+
                "</div>"+
              "</div>"+
            "</div>"+
          "</div>"+
        "</div>"+
 
 
        "<div class=\"w_bottom_1\" id=\""+idBottom+"\">"+         
 
          "<div class=\"w_bottomRight\"  id=\""+idBottomRight+"\">"+
          "</div>"+
 
          "<div class=\"w_bottomLeft\" id=\""+idBottomLeft+"\">"+
          "</div>"+
 
          "<div class=\"w_bottom\" id=\""+idBottom+"\">"+       
          "</div>"+       
 
 
        "</div>"+       
 
 
      "</div>"+
    "</form></div>";
 
    return s;
}

Da die Javascript-Datei der ModalWindow-Komponente automatisch eingebunden wird (da von dieser Klasse abgeleitet wird), muss ich nur diese eine Funktion überschreiben. Ich habe mich in diesem Beispiel darauf beschränkt, den Bereich für die Überschrift und den CloseButton oberhalb des Rahmens darstellen zu lassen (Das div mit der Klasse “w_caption”).

In unsere Komponentenklasse betreten wir nun wieder vertrautes Terrain. Wir leiten von ModalWindow ab und passen ein paar grundsätzliche Dinge an:

package de.wicketpraxis.web.blog.pages.questions.ajax.modal;
 
import org.apache.wicket.ResourceReference;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
import org.apache.wicket.markup.html.CSSPackageResource;
import org.apache.wicket.markup.html.JavascriptPackageResource;
import org.apache.wicket.markup.html.resources.CompressedResourceReference;
import org.apache.wicket.markup.html.resources.JavascriptResourceReference;
 
public class CustomModalWindow extends ModalWindow
{
  private static ResourceReference CSS = new CompressedResourceReference(CustomModalWindow.class, "styles/custom-modal.css");
  private static ResourceReference JAVASCRIPT = new JavascriptResourceReference(CustomModalWindow.class,  "styles/custom-modal.js");
 
  public CustomModalWindow(String id)
  {
    super(id);
 
    setCssClassName("custom");
 
    add(JavascriptPackageResource.getHeaderContribution(JAVASCRIPT));
    add(CSSPackageResource.getHeaderContribution(CSS));
 
    setCloseButtonCallback(new CloseButtonCallback()
    {
      public boolean onCloseButtonClicked(AjaxRequestTarget target)
      {
        return onCloseClicked(target);
      }
    });
 
    setWindowClosedCallback(new WindowClosedCallback()
    {
      public void onClose(AjaxRequestTarget target)
      {
        CustomModalWindow.this.onClose(target);
      }
    });
  }
 
  protected void onClose(AjaxRequestTarget target)
  {
 
  }
 
  protected boolean onCloseClicked(AjaxRequestTarget target)
  {
    return true;
  }
}

Wir setzen die Css-Klasse für den Rahmen, fügen unsere CSS- und Javascript-Anpassungen hinzu (da unsere Referenzen nach den ModalWindow-Referenzen eingebunden werden, überschreiben wir sowohl die CSS-Definitionen als auch die Javascript-Funktionen). Außerdem fügen wir zwei Callbacks hinzu, die auf einen Klick auf das Schließen-Symbol reagieren. Für diese Komponenten benötigen wir keine eigene Markup-Datei.

Jetzt möchten wir diese Komponente endlich verwenden. Dazu legen wir eine Seitenklasse an:

package de.wicketpraxis.web.blog.pages.questions.ajax.modal;
 
import org.apache.wicket.ajax.AbstractAjaxTimerBehavior;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxLink;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.util.time.Duration;
 
public class ModalWindowPage extends WebPage
{
  public ModalWindowPage()
  {
    final CustomModalWindow modalWindow = new CustomModalWindow("modal");
 
    modalWindow.setTitle("Popup");
    modalWindow.setInitialWidth(400);
    modalWindow.setInitialHeight(400);
    modalWindow.setResizable(true);
    modalWindow.setContent(new AbstractModalClosePanel(modalWindow)
    {
      @Override
      public void onClick(AjaxRequestTarget target)
      {
        modalWindow.close(target);
      }
    });
    add(modalWindow);
 
    add(new AjaxLink<Void>("open")
    {
      @Override
      public void onClick(AjaxRequestTarget target)
      {
        modalWindow.show(target);
      }
    });
 
    add(new AbstractAjaxTimerBehavior(Duration.seconds(2))
    {
      @Override
      protected void onTimer(AjaxRequestTarget target)
      {
        modalWindow.show(target);
        stop();
      }
    });
  }
}

Wir erstellen eine Instanz unsere ModalWindow-Komponente und fügen ein Panel als Content-Element hinzu. Dabei wird beim Klick auf den Link innerhalb der Komponente das Fenster geschlossen. Da das ModalWindow per Ajax geöffnet und geschlossen werden muss, benötigen wir zum Öffnen einen AjaxLink. Wenn man dem Nutzer das Fenster bereits beim Aufruf der Seite einmalig anzeigen möchte, kann man sich damit behelfen, das man eine Instanz AbstractAjaxTimerBehavior-Klasse erstellt und die Zeit entsprechend klein wählt (weniger als die zwei Sekunden aus diesem Beispiel). In der onTimer()-Methode führt der Aufruf von stop() dazu, dass die Methode nach der abgelaufenen Zeit nicht noch einmal aufgerufen wird.

<html>
  <head>
    <title>ModalWindow Page</title>
  </head>
  <body>
    <div wicket:id="modal"></div>
    <a wicket:id="open">Open</a>
  </body>
</html>

Und so sieht das Ergebnis aus:

Der Aufwand für eine eigene Komponente ist zwar wesentlich höher als in anderen Fällen, aber der Aufwand lohnt schon deshalb, weil dann das Aussehen der ModalWindow-Kompoente zur restlichen Anwendung passt.

Andere Beiträge

• 9. April 2010 -- Wicket – AbstractEvent Update
• 7. März 2010 -- Wicket Heatmap – Ajax mit Parametern
• 23. Dezember 2009 -- Wicket Ajax Tipp – AjaxRequestTarget nachträglich ermitteln

Wicket bietet die Möglichkeit, neben dem normalen Abschicken eines Formulars auch auf die angeklickten Submit-Buttons reagieren zu können. Damit man aber auch zuverlässig unterscheiden kann, ob der Nutzer das Formular durch ein Enter im Textfeld oder durch einen Klick auf einen Button abgeschickt hat, muss man ein paar Vorbereitungen treffen.

Für das Formular legen wir eine Bean an, welche die Daten aufnimmt.

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

Für unser Beispiel benötigen wir ein Formular, einen AjaxFallbackButton, einen normalen Button und einen Button, den wir dazu benutzen, denn Fall herauszubekommen, wenn der Nutzer einfach nur Enter gedrückt hat. Das FeedbackPanel sollte man auch nicht vergessen.

package de.wicketpraxis.web.blog.pages.questions.form.submit;
 
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.form.AjaxFallbackButton;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.form.Button;
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 FormSubmitPage extends WebPage
{
  int _counter;
 
  public FormSubmitPage()
  {
    final FeedbackPanel feedbackPanel = new FeedbackPanel("feedback");
    feedbackPanel.setOutputMarkupId(true);
    add(feedbackPanel);
 
    CompoundPropertyModel<FormBean> formModel = new CompoundPropertyModel<FormBean>(new FormBean());
    Form<FormBean> form = new Form<FormBean>("form",formModel)
    {
      @Override
      protected void onSubmit()
      {
        info("Form Submit: "+_counter++);
      }
    };
 
    form.add(new TextField<String>("name"));
 
    form.add(new Button("defaultSubmit")
    {
      @Override
      public void onSubmit()
      {
        info("Default Button: "+_counter++);
      }
    });
 
    form.add(new Button("submit")
    {
      @Override
      public void onSubmit()
      {
        info("Button: "+_counter++);
      }
    });
 
    form.add(new AjaxFallbackButton("ajaxSubmit",form)
    {
      @Override
      protected void onSubmit(AjaxRequestTarget target, Form<?> form)
      {
        if (target!=null)
        {
          info("AjaxSubmit Button(ajax): "+_counter++);
          target.addComponent(feedbackPanel);
 
          _counter=0;
        }
        else
        {
          info("AjaxFallbackButton: "+_counter++);
        }
      }
    });
 
    add(form);
  }
 
  @Override
  protected void onBeforeRender()
  {
    _counter=0;
    super.onBeforeRender();
  }
}

Damit man die Reihenfolge besser erkennen kann, mit der die onSubmit-Methoden aufgerufen werden, wird ein Zähler (_counter) hochgezählt und vor dem Darstellen des Formulars wieder zurückgesetzt. In diesem Beispiel liegt die entscheidende Information im Markup. Dabei ist die Reihenfolge der verschiedenen Submit-Komponenten wichtig.

<html>
  <head>
    <title>FormSubmitPage</title>
  </head>
  <body>
    <div wicket:id="feedback"></div>
 
    <form wicket:id="form">
      <input wicket:id="defaultSubmit" type="submit" value="" style="border:0px; width: 0px; height: 0px; visibility: collapse; display: compact;">
      Name <input wicket:id="name"><br>
      <input wicket:id="ajaxSubmit"  type="submit" value="AjaxButton">
      <input wicket:id="submit" type="submit" value="Button"> 
    </form>
  </body>
</html>

Der Button mit der Wicket-ID defaultSubmit muss vor allen anderen Submit-Komponenten stehen. Dadurch wird beim Abschicken des Formulars durch Enter dieser Button ausgewählt. Wenn einer der anderen Buttons angeklickt wird, dann wird das Formular über diesen Button abgeschickt. Doch warum soviel Aufwand? Die onSubmit()-Methode des Formulars wird doch in jedem Fall aufgerufen.

Der Aufwand ist notwendig, wenn man abhängig davon, ob der Nutzer auf einen Button oder eben auf keinen Button geklickt hat, eine Aktion ausführen möchte. Das bedeutet, dass man die Aktion nicht in onSubmit ausführen kann. Es ist allerdings auch nicht möglich, im onSubmit() der Buttonkomponenten ein Flag zu setzen, dass dann in der onSubmit()-Methode des Formulars aufgerufen wird, da die Methode beim AjaxFallbackButton erst nach dem onSubmit() der Komponente aufgerufen wird.

Folgende Ergebnisse erhält man, wenn man das Formular a) per Enter, b) per AjaxButton und c) per Button abschickt:

Submit per Enter

Submit per AjaxButton

Submit per Button

Wenn Javascript deaktiviert ist, dann erhält man folgende Ausgabe:

Submit per Enter

Submit per AjaxButton

Submit per Button

Wenn man dieses Vorgehen beherzigt, funktioniert die Anwendung auch mit deaktiviertem JavaScript genauso zuverlässig. Das freut den Nutzer und in diesem Fall auch den Entwickler:)

Andere Beiträge

• 9. September 2009 -- Migration zu Wicket : Formulare
• 9. April 2010 -- Wicket – AbstractEvent Update
• 7. März 2010 -- Wicket Heatmap – Ajax mit Parametern

Die E-Mail

Als erstes erstellen wir eine Seite, die den Inhalt der E-Mail erzeugen soll:

package de.wicketpraxis.web.blog.pages.questions.email;
 
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;
 
public class EmailContentPage extends WebPage
{
  public EmailContentPage(IModel<List<? extends String>> list)
  {
    add(new ListView<String>("list",list)
    {
      @Override
      protected void populateItem(ListItem<String> item)
      {
        item.add(new Label("name",item.getModel()));
      }
    });
  }
}

Der Code soll zeigen, dass Komponenten ganz normal Funktionieren. Deshalb bekommt die Seite von außen eine Liste mit Werten übergeben, die dann durch eine ListView dargestellt wird.

<h1>TestEmail</h1>
<ul>
  <li wicket:id="list"><span wicket:id="name"></span></li>
</ul>

Im Markup habe ich absichtlich den “Rahmen” der Seite (html > body) weggelassen. Die Klasse und das Markup dienen in diesem Beispiel nur als Platzhalter.

Darstellen und Abschicken

In Wicket sind sehr viele Objekte an den aktuellen Thread gebunden. Das ist notwendig, damit man nicht eine ganze Liste von Objekten als Übergabeparameter durch Methodenaufrufe schleifen muss. Das ist allerdings genau dann ein Problem, wenn wir innerhalb einer Wicketanwendung eine andere Seite darstellen möchten. Außerdem ist es ein Problem, wenn es wie in einem im Hintergrund laufenden Prozess überhaupt keine WicketApplication gibt. Daher erstellen wir uns ein paar Hilfsklassen, die sich um dieses Problem kümmern.

package de.wicketpraxis.web.blog.pages.questions.email;
 
public interface WicketCallback<I,O>
{
  public O getResult(I input);
}

package de.wicketpraxis.web.blog.pages.questions.email;
 
import java.util.logging.Logger;
 
public class WicketThreadAdapter<I,O> extends Thread
{
  private static final Logger _logger = Logger.getLogger(WicketThreadAdapter.class.getName());
 
  Object _lock=new Object();
 
  WicketCallback<I, O> _callback;
  I _input;
  O _output;
  boolean _done=false;
 
  protected WicketThreadAdapter(WicketCallback<I, O> callback, I input)
  {
    _callback=callback;
    _input=input;
  }
 
  @Override
  public void run()
  {
    synchronized (_lock)
    {
      _output=_callback.getResult(_input);
      _done=true;
      _lock.notify();
    }
  }
 
  protected O getResult() throws InterruptedException
  {
    synchronized (_lock)
    {
      while (!_done)
      {
        _lock.wait();
      }
      return _output;
    }
  }
 
  public static <I,O> O getResult(WicketCallback<I, O> callback, I input) throws InterruptedException
  {
    WicketThreadAdapter<I,O> threadAdapter = new WicketThreadAdapter<I,O>(callback,input);
    threadAdapter.start();
    return threadAdapter.getResult();
  }
}

Die WicketThreadAdapter-Klasse wird über die statische Methode getResult(…) angesprochen und macht folgendes: Es wird ein neuer Thread erzeugt. Im laufenden Thread wird der Callback aufgerufen und der Thread beendet. Das Ergebnis, das im Thread ermittelt wurde, wird als Ergebnis herausgereicht. Kurz: Das Ergebnis wird in einem anderen Thread als dem aktuellen ermittelt und führt so nicht zu Kollisionen mit der laufenden Anwendung.

Der Trick

Das alles führt noch nicht zum Ziel. Wir müssen uns jetzt noch darum kümmern, dass wir die Seite dargestellt bekommen. Dazu benutzten wir die Klasse BaseWicketTester, die sich um alles weitere kümmert. Dort übergeben wir die Seite, die wir darstellen wollen. Dann können wir auf den Inhalt der Seite zugreifen und als Ergebnis zurück liefern.

package de.wicketpraxis.web.blog.pages.questions.email;
 
import java.util.Arrays;
import java.util.List;
 
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.model.Model;
import org.apache.wicket.util.tester.BaseWicketTester;
 
public class EmailFromComponentPage extends WebPage
{
  public EmailFromComponentPage()
  {
    WicketCallback<List<String>, String> callback = new WicketCallback<List<String>, String>()
    {
      public String getResult(List<String> input)
      {
        final IModel<List<? extends String>> listModel = Model.ofList(input);
 
        BaseWicketTester tester=new BaseWicketTester();
        tester.startPage(new EmailContentPage(listModel));
        return tester.getServletResponse().getDocument();
      }
    };
 
    String result;
    try
    {
      result = WicketThreadAdapter.getResult(callback, Arrays.asList("Klaus","Susi","Bert"));
    }
    catch (InterruptedException e)
    {
      e.printStackTrace();
      result=e.getLocalizedMessage();
    }
 
    add(new Label("email",result).setEscapeModelStrings(false));
  }
}

Damit das Ergebnis richtig angezeigt wird, teilen wir dem Label “email” mit, dass es den Text nicht umschreiben soll.

<html>
  <head>
    <title>Email Form Component</title>
  </head>
  <body>
    Email <span wicket:id="email"></span>
  </body>
</html>

Wenn man die Seite aufruft, erhält man dann folgende Darstellung:

Ergebnis: Html-E-Mail aus Wicket

Wenn man die E-Mail durch Hintergrundprozesse versenden möchte, ist ein eigener Thread unnötig, weil keine WicketApplication-Klasse an den Thread gebunden ist. Dann sollte der Einsatz der BaseWicketTester-Klasse reichen. Es ist allerdings darauf zu achten, dass alles, was in der eigenen Application-Klasse definiert wurde, an dieser Stelle nicht ohne weiteres zur Verfügung steht (z.B. wird der OpenSessionInViewFilter für Spring nicht aufgerufen, die SpringBean-Annotationen sind ebenfalls funktionslos).

Fazit

Auch wenn sicher noch die eine oder andere Anpassung notwendig ist, damit man Komponenten sowohl für die Anwendung als auch für den E-Mail-Versand benutzten kann, lohnt sich der Aufwand, weil man a) auf die vielfältigen Möglichkeiten, die Wicket als “Template-Engine” bietet, zurückgreifen kann, b) man sich im besten Fall doppelten Code ersparen kann und c) man keine zweite Lösung einbinden muss. Und wieder hat mich Wicket ein wenig überrascht. Weil es dann doch so einfach ging:)

Andere Beiträge

• 16. Juni 2009 -- Wicket ohne Template
• 29. April 2011 -- Wicket – Back Button zuverlässig erkennen
• 24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB

Die folgenden Grafiken sind das vorläufige Zwischenergebnis. Es ist nicht auszuschließen, dass es Fehler gibt. Für jeden gemeldeten Fehler bin ich daher sehr dankbar, aber auch Anregungen sind natürlich herzlich willkommen.

Wicket Kompontenten – Basis

Wicket Komponenten inklusive Extensions

Wicket Modelle

Wicket Behavior

Wicket Listener

Wicket RequestTarget

Andere Beiträge

• 15. Juli 2010 -- Wicket – Flexibilität mit Factories
• 5. Januar 2010 -- Wicket – lose Koppelung von Komponenten
• 10. Dezember 2009 -- Praxisbuch Wicket – Übersicht

Andere Beiträge

• No Related Post

Wenn man bisher mit einer Reihe von Java-Klassen ein Framework für eine bestimmte Aufgabe entwickelt hat, kann man die selbe Anforderung mit einigen wenigen Scala-Klassen abbilden.

Das bedeutet, dass sich die Funktionalität mit sehr viel weniger Code darstellen lässt. Das spiegelt die Befürchtung wieder, dass man mit Scala Code schreiben kann, der schwer zu vestehen ist. Doch dieser erste Anschein trügt. Der Code ist nur um vielfaches dichter und deshalb natürlich schwerer zu verstehen als ähnlich umfangreicher Java-Code. Der funktionsäquivalente Java-Code wäre aber entsprechend umfangreicher und kann im Zweifel schon deshalb nicht ansatzweise so gut überblickt werden. Ich kann es daher nicht nachvollziehen, dass dieser Punkt gegen Scala sprechen soll.

Ich glaube, dass die Entwicklung bei Scala insofern noch am Anfang steht, als dass das Ausloten der Sprachemöglichkeiten und die kreativen Auslegungen der Plattform noch in den Kinderschuhen steckt, gerade wenn man betrachtet, wo wir uns da im Java-Umfeld befinden. Doch diese Kinderschuhe sind bereits jetzt viel größer und der kleine Bub schaut entspannt über die Köpfe seiner Eltern hinweg.

Andere Beiträge

• 19. Juni 2009 -- Wicket und Scala – der Rückweg ist anstrengend
• 21. Juli 2009 -- Wicket saved the day
• 21. Juli 2009 -- Sails – die Scala Version von Rails/Grails

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

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

Andere Beiträge

• 11. Mai 2009 -- Die Ruhe vor dem Sturm
• 15. September 2009 -- Migration zu Wicket: Ajax
• 12. September 2009 -- Entscheidungshilfe Webframework

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.

Andere Beiträge

• 15. September 2009 -- Migration zu Wicket: Ajax
• 9. April 2010 -- Wicket – AbstractEvent Update
• 7. März 2010 -- Wicket Heatmap – Ajax mit Parametern