wicket praxis » Allgemein

Wicket Ajax – IAjaxRegionMarkupIdProvider

admin — Wed, 18 May 2011 07:00:01 +0000

Fast unbemerkt versammeln sich in den Wicket-Updates neben einer Reihe von Bugfixes kleine Anpassungen, die das Entwickeln mit Wicket einfacher machen können. Da man nicht bei jedem Update nachsieht, was sich verändert hat, weil die Erfahrung gezeigt hat, dass man bei Wicket eigentlich immer auf die aktuelle Version wechseln kann, läuft man Gefahr, dass man wichtige Anpassungen verpasst. Deshalb stelle ich heute eine Erweiterung von Wicket vor, die in meinen Augen ein erhebliches Potential bietet: das Interface IAjaxRegionMarkupIdProvider.

Über dieses Interface ist es möglich, Wicket mitzuteilen, welches Seitenelement in einem Ajax-Response eigentlich ersetzt werden soll. So ist es möglich, z.B. in einem Behavior vor und nach der Komponente Html-Markup einzufügen, dass bei Aktualisierung der Komponente ebenfalls ersetzt wird. Was sich kompliziert anhört ist in der Anwendung recht einfach. Wir implementieren ein Interface, dass einen roten Rahmen um eine Komponente ziehen soll, die per Ajax aktualisiert wird.

package de.wicketpraxis.web.blog.pages.questions.ajax.behavior;
 
import org.apache.wicket.Component;
import org.apache.wicket.ajax.IAjaxRegionMarkupIdProvider;
import org.apache.wicket.behavior.AbstractBehavior;
 
 
public class AjaxRegionBehavior extends AbstractBehavior implements IAjaxRegionMarkupIdProvider {
 
  @Override
  public void beforeRender(Component component) {
    component.getResponse().write("\"border:1px solid red;\" id=\""+getAjaxRegionMarkupId(component)+"\">");
    super.beforeRender(component);
  }
 
  @Override
  public void onRendered(Component component) {
    super.onRendered(component);
    component.getResponse().write("
");  }
 
  @Override
  public String getAjaxRegionMarkupId(Component component) {
    return component.getMarkupId()+"_border";
  }
 
}

Das Behavior funktioniert wie folgt: In beforeRender() und in onRendered() wird um die Komponente herum ein div-Tag mit passender Style-Anweisung geschrieben. Hierbei muss in beforeRender() die id des Tags auf den Wert gesetzt werden, den Wicket dann auch über die Interface-Methode getAjaxRegionMarkupId() bekommt. Das führt dazu, dass Wicket die Ersetzung per Ajax automatisch auf den durch das Behavior definierten Rahmen, eben die ID, die per getAjaxRegionMarkupId() definiert wurde, ausweitet.

Die Anwendung ist recht einfach:

package de.wicketpraxis.web.blog.pages.questions.ajax.behavior;
 
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.markup.html.basic.Label;
import org.apache.wicket.model.Model;
 
 
public class AjaxRegionPage extends WebPage {
 
 
  private Model<Integer> _counter;
 
  public AjaxRegionPage() {
 
    _counter = Model.of(0);
    final Label label=new Label("label",_counter);
    label.setOutputMarkupId(true);
    label.add(new AjaxRegionBehavior());
    add(label);
 
    add(new AjaxLink<Integer>("link",_counter) {
      @Override
      public void onClick(AjaxRequestTarget target) {
        setModelObject(1+getModelObject());
        target.addComponent(label);
      }
    });
  }
}

Wie man im Code-Beispiel sehen kann, wird das Behavior zur Komponente hinzugefügt. Würde man das Interface nicht implementieren, würden bei jeder Aktualisierung immer neue rote Rahmen um die Komponente entstehen.

<html>
  <head>
    <title>AjaxRegion Page</title>
  </head>
  <body>
    <span wicket:id="label"></span>
    <a wicket:id="link">Count</a>
  </body>
</html>

Bisher war es nötig, diese Anforderung immer auf Komponenten abzubilden, die dann korrekt ersetzt werden mussten. Damit ist es jetzt sehr viel einfacher möglich, Eine Komponente zu dekorieren und diese Dekoration auch per Ajax korrekt zu ersetzten. Auch wenn der erste Gedanke einer Anwendung sich vermutlich um Formularfelder mit fehlerhaften Eingaben dreht, gibt es unzählige Möglichkeiten, wo diese Funktionalität die Entwicklung nachhaltig vereinfachen wird.

Share and Enjoy:

Andere Beiträge

No Related Post

Wicket – Back Button zuverlässig erkennen

michael — Fri, 29 Apr 2011 06:22:31 +0000

Die Entwicklung moderner Webanwendungen orientiert sich zunehmend am Interaktionsmodel wie es Desktopanwendungen bieten. Wicket unterstütz dabei erheblich, in dem z.B. der Einsatz von Ajax keine große Hürde mehr darstellt. Eine Interaktionsmöglichkeit ist Desktopanwendungen doch bisher eher fremd: der Back Button im Browser. Der Nutzer erwartet, dass er auf einen vorherigen Zustand zurück navigieren kann. Je komplexer die Webanwendung, desto aufwendiger war es mit anderen Frameworks, die Nutzererwartung auch in ein sinnvolles Anwendungsverhalten zu übertragen. Wicket bietet mit versionierten Seiten bereits eine gute Unterstützung, die einem Entwickler ermöglicht, die kleine “Zeitreise”, die der Nutzer vornimmt, auf Anwendungsseite entsprechend abbilden zu können.

Trotzdem möchte man unter Umständen wissen, dass der Nutzer den Back Button betätigt hat, weil es vielleicht auch einen Rückschluss darauf zulässt, dass der Nutzer in der Anwendung nicht die richtige Interaktionsmöglichkeit gefunden hat (z.B. in einem Bestellvorgang doch nochmal die Anschrift ändern zu wollen).

Folgendes Beispiel ist eine Möglichkeit, zu erkennen, ob der Nutzer mit dem Browser vor und zurück navigiert hat. Dabei gibt es zwei Dinge zu beachten. Der erste Seitenaufruf darf nicht in einer Url enden, die den Konstruktor der Seite aufruft. Denn dann sieht das aus Anwendungssicht so aus, als ob der Nutzer erneut auf die Seite navigiert ist. Zum zweiten muss man den Browser dazu zwingen, die Seite in jedem Fall neu vom Server abzurufen.

Daher brauchen wir zu erst eine Sprungseite:

package de.wicketpraxis.web.blog.pages.questions.backbutton;
 
import org.apache.wicket.markup.html.WebPage;
 
public class BackButtonStartPage extends WebPage {
 
  public BackButtonStartPage() {
    setResponsePage(new BackButtonPage());
    setRedirect(true);
  }
}

Die Sprungseite ruft die eigentliche Seite auf. Außerdem ist der Aufruf von setRedirect() notwendig, damit nicht nur die neue Seite dargestellt wird, sondern sich auch die Url entsprechend ändert.

Die Seite mit der Erkennung der Button-Nutzung sieht dann wie folgt aus:

package de.wicketpraxis.web.blog.pages.questions.backbutton;
 
import java.util.Date;
 
import org.apache.wicket.MetaDataKey;
import org.apache.wicket.Session;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.link.Link;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.protocol.http.WebResponse;
 
public class BackButtonPage extends WebPage {
 
  static final TimeStampKey KEY = new TimeStampKey();
  private long _pageInitTimeStamp;
 
  public BackButtonPage() {
    //setVersioned(true);
 
    _pageInitTimeStamp = new Date().getTime();
    setPageTimeStamp(_pageInitTimeStamp);
 
    add(new FeedbackPanel("feedback"));
 
    add(new Link<Void>("link") {
 
      @Override
      public void onClick() {
        setResponsePage(new BackButtonPage());
      }
    });
  }
 
  private static void setPageTimeStamp(long timeStamp) {
    Session.get().setMetaData(KEY, timeStamp);
  }
 
  @Override
  protected void onBeforeRender() {
    super.onBeforeRender();
 
    Long lastPageRendered = Session.get().getMetaData(KEY);
    setPageTimeStamp(_pageInitTimeStamp);
 
    if (lastPageRendered > _pageInitTimeStamp) {
      info("BackButton pressed");
    }
    if (lastPageRendered < _pageInitTimeStamp) {
      info("ForwardButton pressed");
    }
  }
 
  @Override
  protected void configureResponse() {
    super.configureResponse();
    WebResponse response = getWebRequestCycle().getWebResponse();
    response.setHeader("Cache-Control", "no-cache, max-age=0,must-revalidate, no-store");
  }
 
  static class TimeStampKey extends MetaDataKey<Long> {
 
  }
}

Das Markup der Seite:

<html>
  <head>
    <title>BackButton Page</title>
  </head>
  <body>
    <div wicket:id="feedback"></div>
    <a wicket:id="link">Link</a>
  </body>
</html>

Das Prinzip funktioniert wie folgt: Die Seite bekommt einen Zeitstempel über den Zeitpunkt der Erstellung. Dieser Zeitpunkt wird außerdem als Metainformation in die Session gesetzt (Hinweis: um diese Funktion bei mehr als einer Seite benutzen zu können, ist natürlich etwas mehr Aufwand nötig). Das bedeutet, dass jede Version der Seite einen eigenen Zeitstempel hat. In onBeforeRender() kann man nun prüfen, ob diese Seite auch die aktuelle Seite ist, oder ob der Nutzer auf einen neuere oder ältere Version zurückgegriffen hat. Der Link dient dazu, immer neue Version der Seite zu erzeugen.

Damit der Browser die Seite aber in jedem Fall neu lädt, muss man entsprechende Header in den Http-Response einfügen. Eine Möglichkeit besteht darin, die configureResponse()-Methode entsprechend zu überschreiben.

Wenn man nun auf der Seite den Link klickt und dann mit dem Back Button oder dem Forward Button navigiert, erscheinen die entsprechenden Hinweise auf der Seite.

Share and Enjoy:

Andere Beiträge

24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB
15. Juli 2010 -- Wicket – Flexibilität mit Factories
14. April 2010 -- Wicket Eclipse Plugin – qwickie

Wicket – Mainstream, Github, MongoDB

michael — Sun, 24 Oct 2010 09:45:57 +0000

In den letzten Wochen und Monaten habe ich recht wenig neues über Wicket gelesen. Man könnte meinen, dass es ruhig geworden ist um Wicket. Doch wenn man sich z.B. die Mailinglisten ansieht, spricht das eine deutlich andere Sprache. Jobangebote fragen zunehmend ab, ob Wicket-KnowHow vorhanden ist. Man sieht mehr und mehr Anwendungen, die mit Wicket realisiert wurden. Wicket ist im Mainstream angekommen.

Vielleicht ist das auch nur eine sehr persönliche Sichtweise, aber ich glaube, das auch Git im Mainstream angekommen ist. Git wurde bereits in bestimmten Bereichen auf einer breiten Basis eingesetzt. Aber der bedeutende Unterschied liegt darin, dass man sich bei neuen Projekten eigentlich immer die Frage stellt: Subversion oder besser gleich Git?

Ich habe alle meine Projekte von Subversion auf Git umgestellt und dabei gemerkt, das Subversion und Git nicht wirklich aufeinander abbildbar sind, aber die Vorteile die Git mitbringt sich selbst dann auszahlen, wenn man Git noch wie Subversion benutzt. Man findet ab jetzt die Quelltexte für das Buch bei Github unter http://github.com/michaelmosmann/wicket-praxis.git.

Da ich in meinen aktuellen Projekten mich mit der Frage beschäftigt habe, ob nicht eine Dokumentendatenbank wie MongoDB die bessere Alternative ist, sei an dieser Stelle auch noch auf einen Objektmapper verwiesen, denn in ich diesem Zusammenhang entwickelt habe: http://github.com/michaelmosmann/mongoom.flapdoodle.de

In Zukunft an dieser Stelle wieder mehr und dann vielleicht rund um Wicket in Zusammenarbeit mit Dokumentendatenbanken.

Share and Enjoy:

Andere Beiträge

29. April 2011 -- Wicket – Back Button zuverlässig erkennen
15. Juli 2010 -- Wicket – Flexibilität mit Factories
14. April 2010 -- Wicket Eclipse Plugin – qwickie

Wicket Eclipse Plugin – qwickie

michael — Wed, 14 Apr 2010 06:28:47 +0000

Zufällig bin ich auf ein Wicket-Eclipse-Plugin gestoßen, dass im täglichen Umgang mit Wicket-basierten Projekten zu einer nicht unwesentlichen Arbeitserleichterung führt. In Anbetracht des frühen Entwicklungsstadiums (Version 0.1) ist das bereits eine reife Leistung.

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.

Share and Enjoy:

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

Wicket Extensions – Anpassungen am ModalWindow

admin — Wed, 03 Mar 2010 07:42:18 +0000

Wicket liefert im Bereich Extensions Komponenten mit, die zwar nicht direkt zum Kern von Wicket gehören, die aber fast so häufig wie die Standardwicketkomponenten zum Zuge kommen. Im folgenden Beitrag zeige ich, wie man die ModalWindow-Komponente benutzen kann und wie man die Darstellung an eigene Wünsche anpasst. Als erstes benötigen wir eine Komponente, die durch das ModalWindow angezeigt werden soll.

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:


  <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 =
      "\"wicket-modal\" id=\""+idWindow+"\" style=\"top: 10px; left: 10px; width: 100px;\">"+
      "\""+idClassElement+"\">"+
        "\"w_caption\"  id=\""+idCaption+"\">"+
          "\"w_close\" href=\"#\">"+                 
          "\""+idCaptionText+"\" class=\"w_captionText\">"+
        "
"+ 
        "\"w_top_1\">"+
 
        "\"w_topLeft\" id=\""+idTopLeft+"\">"+
        ""+       
 
        "\"w_topRight\" id=\""+idTopRight+"\">"+
        ""+
 
        "\"w_top\" id='"+idTop+"'>"+                 
        ""+
 
        ""+
 
        "\"w_left\" id='"+idLeft+"'>"+
          "\"w_right_1\">"+
            "\"w_right\" id='"+idRight+"'>"+
              "\"w_content_1\" onmousedown=\"if (Wicket.Browser.isSafari()) { event.ignore = true; }  else { Wicket.stopEvent(event); } \">"+                                      
 
                "\"w_content_2\">"+
                "\"w_content_3\">"+
                  "\"w_content\">";
        if (isFrame) {
          if (Wicket.Browser.isIELessThan7() || !Wicket.Browser.isIE()) {                       
            s+= "\/\/:' frameborder=\"0\" id='"+idContent+"' allowtransparency=\"false\" style=\"height: 200px\">"+
                    "";
          } else {
            s+= "\"0\" id='"+idContent+"' allowtransparency=\"false\" style=\"height: 200px\">"+
            "";
          }
        } else {
          s+=
                    "
";
        }
          s+=             
                  ""+
                ""+
                ""+
              ""+
            ""+
          ""+
        ""+
 
 
        "\"w_bottom_1\" id=\""+idBottom+"\">"+         
 
          "\"w_bottomRight\"  id=\""+idBottomRight+"\">"+
          ""+
 
          "\"w_bottomLeft\" id=\""+idBottomLeft+"\">"+
          ""+
 
          "\"w_bottom\" id=\""+idBottom+"\">"+       
          ""+       
 
 
        ""+       
 
 
      ""+
    "";
 
    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.

Share and Enjoy:

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

Buchkritik bei it-republik.de

michael — Thu, 11 Feb 2010 08:46:12 +0000

Danke für die gute Rezension.

Share and Enjoy:

Andere Beiträge

19. Oktober 2009 -- Wicketbuch aus dem dpunkt Verlag
9. September 2009 -- Wicket im JavaMagazin
27. Mai 2009 -- Wicket Praxis als Buch

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
29. April 2011 -- Wicket – Back Button zuverlässig erkennen
24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB

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
29. April 2011 -- Wicket – Back Button zuverlässig erkennen
24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB

Wicket und Eclipse

michael — Wed, 13 Jan 2010 06:24:20 +0000

Um mit Wicket Anwendungen entwickeln zu können, benötigt man eine vernünftige Java-Entwicklungsumgebung, die auch Html-Dateien bearbeiten kann. Das reicht für den Anfang. Doch im Laufe der Zeit wünscht man sich für verschiedene Dinge eine besser Unterstützung, weil man damit besonders häufig in Berührung kommt und der Effekt daher spürbar wäre. Manchmal erzielen kleine Dinge daher eine große Wirkung.

So habe ich mich bisher gescheut, für Wicket entsprechende Templates in Eclipse zu Pflegen, weil ich dachte, dass sich der Aufwand nicht lohnt, weil man davon nicht ausreichend profitiert. Das war bis vor ein paar Tagen so. Als ich dann merkte, dass ich immer häufiger “wicket:id” tippen musste, fügte ich dafür ein passendes Template in Eclipse hinzu. Es funktionierte wie erwartet und ich konnte etwas flüssiger arbeiten. Schon am darauf folgenden Tag benutzte ich in einem anderen Projekt ein neuen Workspace. Als ich das erste mal wieder “wicket:id” schreiben wollte und nun auf die Unterstützung von Eclipse wartete, fiel mir auf, was mir fehlt: in dem Projekt waren die Wicket-Templates noch nicht eingebunden.

Damit man sich nicht selbst hinsetzen muss und diese Templates in Eclipse konfigurieren muss, hier die Datei zum download.

Share and Enjoy:

Andere Beiträge

14. April 2010 -- Wicket Eclipse Plugin – qwickie
27. Oktober 2009 -- Wicket Tipps: Markup
29. April 2011 -- Wicket – Back Button zuverlässig erkennen

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
29. April 2011 -- Wicket – Back Button zuverlässig erkennen