wicket praxis

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("");
    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 _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("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.


  
    AjaxRegion Page
  
  
    
    Count

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.

Andere Beiträge

No Related Post

Wicket – Komponentenübersicht (1.4.17)

michael — Sun, 15 May 2011 08:48:50 +0000

Seit Wicket 1.4.1 haben sich bei den Komponenten und Interfaces ein paar Anpassungen ergeben, so dass ich die Komponentenübersichten aktualisiert habe. Folgende Diagramme beziehen sich auf die Version 1.4.17.

Wicket Kompontenten – Basis

Wicket Komponenten inklusive Extensions

Wicket Modelle

Wicket Behavior

Wicket Listener

Wicket RequestTarget

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("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 {

  }
}

Das Markup der Seite:


  
    BackButton Page
  
  
    
    Link

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.

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.

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 – 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 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
{
  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
{
  private final IComponentFactory _content;
  private final IModel _style;

  public BorderPanelFactory(IComponentFactory content, IModel 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 content,IModel 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):

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 redBorderStyle = Model.of("border:1px solid red; background-color: #fff0f0;");
    Model greenBorderStyle = Model.of("border:1px solid green; background-color: #f0fff0;");
    Model 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:


  
    ComponentFactory Page

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
{
  private final IComponentFactory _left;
  private final IComponentFactory _right;

  public TwoInARowFactory(IComponentFactory left, IComponentFactory 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 left, IComponentFactory 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:

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 redBorderStyle = Model.of("border:1px solid red; background-color: #fff0f0;");
    Model greenBorderStyle = Model.of("border:1px solid green; background-color: #f0fff0;");
    Model 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:


  
    ComponentFactory Page

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?

Andere Beiträge

5. Januar 2010 -- Wicket – lose Koppelung von Komponenten
16. Oktober 2009 -- Wicket Komponentenübersicht
29. April 2011 -- Wicket – Back Button zuverlässig erkennen

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.

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 – AbstractEvent Update

admin — Fri, 09 Apr 2010 07:20:31 +0000

Wie ich bereits beschrieben habe, kann man mit Wicket relativ leicht eine lose Koppelung von Komponenten über einen Event-Mechanismus erreichen. Dabei wurden bisher nur Komponenten berücksichtigt. Manchmal ist es aber sinnvoll, die Behandlung dieser Events an einer zentralen Stelle durchzuführen. Daher habe ich die Basisklasse leicht erweitert. Dabei ist der Visitior in eine eigene Klasse gewandert. Außerdem ist es wesentlich geschickter, auch bei nicht Ajax-Requests mit Events zu arbeiten. Die Modifikation des EventListener-Interface trägt dem Rechnung.

package de.wicketpraxis.web.blog.pages.questions.events;

public interface EventListenerInterface
{
  public void notifyEvent(AbstractEvent event);
}

Die Methode lautet nun notifyEvent statt notifyAjaxEvent.

package de.wicketpraxis.web.blog.pages.questions.events;

import org.apache.wicket.Component;
import org.apache.wicket.Component.IVisitor;

public class NotifyVisitor implements IVisitor 
{
  private final AbstractEvent _event;
   
  public NotifyVisitor(final AbstractEvent event)
  {
    _event = event;
  }
   
  public Object component(final Component component)
  {
    if (component instanceof EventListenerInterface) 
    {
      ((EventListenerInterface) component).notifyEvent(_event);
    }
    return IVisitor.CONTINUE_TRAVERSAL;
  }
}

Der Event sucht jetzt nicht nur in allen Komponenten nach dem EventListenerInterface, sondern auch in der Application, der Session und der Page.

package de.wicketpraxis.web.blog.pages.questions.events;

import org.apache.wicket.Application;
import org.apache.wicket.Component;
import org.apache.wicket.Page;
import org.apache.wicket.Session;
import org.apache.wicket.Component.IVisitor;
import org.apache.wicket.ajax.AjaxRequestTarget;

public class AbstractEvent
{
  private final Component _source;
  protected final AjaxRequestTarget _target;
  
  public AbstractEvent(final Component source, AjaxRequestTarget target)
  {
    _source = source;
    _target = target;
  }
  
  public AbstractEvent(final Component source)
  {
    this(source,null);
  }
  
  public Component getSource()
  {
    return _source;
  }
  
  /**
   * notify Application, Session, Page and Components
   */
  public final void fire()
  {
    Page page=getSource().getPage();
    
    Application application=page.getApplication();
    if (application instanceof EventListenerInterface)
    {
      ((EventListenerInterface) application).notifyEvent(this);
    }
    Session session=page.getSession();
    if (session instanceof EventListenerInterface)
    {
      ((EventListenerInterface) session).notifyEvent(this);
    }
    if (page instanceof EventListenerInterface)
    {
      ((EventListenerInterface) page).notifyEvent(this);
    }
    page.visitChildren(EventListenerInterface.class, getVisitor());
    onAfterFire();
  }

  protected  void onAfterFire()
  {
    
  }

  protected IVisitor getVisitor()
  {
    return new NotifyVisitor(this);
  }

  public AjaxRequestTarget getTarget()
  {
    return _target;
  }
  
  public boolean isAjax()
  {
    return _target!=null;
  }

  public final void update(Component component)
  {
    if (_target!=null)
    {
      _target.addComponent(component);
    }
  }

}

Hinzugekommen ist außerdem die Funktion onAfterFire() die aufgerufen wird, sobald alle möglichen Listener benachrichtig wurden. An dieser Stelle könnte man dann Prüfungen einbauen, ob z.B. der Event überhaupt ein Ziel erreicht hat.

Ich glaube, dass diese Lösung zu offensichtlich war, so dass man sie leicht übersehen konnte.

Andere Beiträge

7. März 2010 -- Wicket Heatmap – Ajax mit Parametern
3. März 2010 -- Wicket Extensions – Anpassungen am ModalWindow
23. Dezember 2009 -- Wicket Ajax Tipp – AjaxRequestTarget nachträglich ermitteln

Wicket Heatmap – Ajax mit Parametern

michael — Sun, 07 Mar 2010 15:22:07 +0000

Wer wissen möchte, wohin die Nutzer in der eigenen Anwendung so klicken (z.B. auf Dinge, von denen man selbst nicht annehmen würde, das Nutzer darauf klicken), der muss jeden Mausklick des Nutzers aufzeichnen. Aus diesen Daten kann man dann ermitteln, wohin die Nutzer ihren Mauszeiger so wandern lassen. Dafür gibt es bereits Opensourcelösungen, die meist auf PHP basieren. Unter dem Suchbergriff Heatmap wird man auch bei Google fündig. Da sich alles in diesem Blog um Java und dann noch um Wicket dreht, lag es natürlich nahe, zu prüfen, ob und wie man diese Anforderung mit Wicket realisieren kann. Dieser Beitrag wäre viel kürzer, wenn man die Frage nach dem “ob” mit nein beantworten müsste. Kommen wir also zum “wie?”.

Für die Umsetzung habe ich mir anfänglich einiges aus dem Beispielen aus folgendem Blogbeitrag entlehnt. Im Laufe der Zeit ist zwar davon nicht mehr viel zu sehen, das Grundprinzip ist aber das Gleiche geblieben.

Folgende Fragestellung stand am Anfang dieses Versuchs: Wie kann man mit Wicket Werte in einem AjaxRequest übergeben (z.B. die Mausposition). Die erste Idee bestand darin, ein unsichtbares Formular zu erstellen, in das man die Werte per Javascript einfügt und dieses Formular per Ajax abschickt. Das hat auch funktioniert, war aber irgendwie auch ein wenig zu aufwendig. Nach einer Reihe missglückter Versuche, den richtigen Ansatz zu finden, stellte ich diese Frage in der Wicket-Mailingliste und bekam den entscheidenen Tipp von Ernesto Reinaldo Barreiro. Es gab einen Vortrag der London Wicket User Group, der dieses Problem löste. Mit dieser Vorarbeit begann ich das Thema umzusetzen. Dabei hat sich die eigene Implementierung vom Original entfernt. Hier nun Schritt für Schritt der vollständige Code:

AbstractParameterizedDefaultAjaxBehavior

package de.wicketpraxis.web.blog.pages.questions.ajax.parameter;

import java.util.HashMap;
import java.util.Map;

import org.apache.wicket.Request;
import org.apache.wicket.RequestCycle;
import org.apache.wicket.ResourceReference;
import org.apache.wicket.ajax.AbstractDefaultAjaxBehavior;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.util.time.Duration;

public abstract class AbstractParameterizedDefaultAjaxBehavior extends AbstractDefaultAjaxBehavior
{
  static int sec=0;
  
  private Duration _throttleDelay;

  @Override
  public void renderHead(IHeaderResponse response)
  {
    super.renderHead(response);
    response.renderJavascriptReference(new ResourceReference(AbstractParameterizedDefaultAjaxBehavior.class,"AbstractParameterizedDefaultAjaxBehavior.js"));
  }
  
  @Override
  protected void respond(AjaxRequestTarget target)
  {
    Request request = RequestCycle.get().getRequest();
    
    Map map=new HashMap();
    Parameter[] parameter = getParameter();
    for (Parameter p : parameter)
    {
      String svalue = request.getParameter(p.getName());
      if (svalue!=null)
      {
        Object value=getComponent().getConverter(p.getType()).convertToObject(svalue, getComponent().getLocale());
        map.put(p.getName(), value);
      }
    }
    
    respond(target, new ParameterMap(map));
  }
  
  @Override
  public CharSequence getCallbackUrl(boolean onlyTargetActivePage)
  {
    StringBuilder sb=new StringBuilder();
    sb.append(super.getCallbackUrl(onlyTargetActivePage));
    
    Parameter[] parameter = getParameter();
    for (Parameter p : parameter)
    {
      sb.append("&").append(p.getName()).append("='+").append(p.getJavascript()).append("+'");
    }
    
    return sb.toString();
  }
  
  @Override
  protected final CharSequence getCallbackScript()
  {
    if (_throttleDelay!=null)
    {
      return throttleScript(super.getCallbackScript(),"thw"+(sec++),_throttleDelay);
    }
    return super.getCallbackScript();
  }
  
  protected static class Parameter
  {
    String _name;
    String _javascript;
    Class _type;
    
    protected Parameter(String name,Class type,String javascript)
    {
      _name=name;
      _type=type;
      _javascript=javascript;
    }
    
    protected String getName()
    {
      return _name;
    }
    protected String getJavascript()
    {
      return _javascript;
    }
    protected Class getType()
    {
      return _type;
    }
  }
  
  protected static  Parameter of(String name,Class type,String javascript)
  {
    return new Parameter(name, type, javascript);
  }
  
  protected static class ParameterMap
  {
    Map _map;
    
    protected ParameterMap(Map map)
    {
      _map=map;
    }
    
    public  T getValue(Parameter parameter)
    {
      return (T) _map.get(parameter.getName());
    }
  }
  
  public final AbstractParameterizedDefaultAjaxBehavior setThrottleDelay(Duration throttleDelay)
  {
    _throttleDelay=throttleDelay;
    return this;
  }
  
  protected abstract void respond(AjaxRequestTarget target,ParameterMap parameterMap);
  
  protected abstract Parameter[] getParameter();

}

Die drei wichtigsten Bestandteile dieser Klasse sind folgende: Die Klasse Parameter definiert den Namen, den Typ, und das Javascript, das für das Ermitteln des Wertes im Browser aufgerufen muss. Die Methode respond(AjaxRequestTarget) liest die Werte aus dem Request aus, konvertiert diese in den gewünschen Typ und ruf damit eine zu überschreibende Methode auf. Die Methode getCallbackUrl() liefert das Javascript-Fragment für die Url, die dann per Ajax aufgerufen wird.

Um die Position des Mauszeigers ermitteln zu können, muss man sich mit einer eigenen Funktion für so einen Event registrieren. Damit mehr als eine Funktion auf so einen Event reagieren kann, sollte man die Funktion, die davor registriert war, ebenfalls aufrufen. Um für diese Problematik, die vermutlich in allen abgeleiteten Klassen vorhanden ist, besser lösen zu können, binden wir automatisch eine hilfreiche Javascript-Klasse ein.

Callback = {
  create: function(oldCallback,newCallback)
  {
    return function(a,b,c,d,e,f)
    {
      if (oldCallback) 
      {
        oldCallback(a,b,c,d,e,f);
      }
      newCallback(a,b,c,d,e,f);
    }
  },
};

Der Code sieht etwas merkwürdig aus. Das liegt an folgenden Gründen: zum einen stehe ich mit Javascript immer noch auf Kriegsfuß (mit Wicket kann man den Javascript-Teil sehr schön verstecken) und habe daher keine geeignete Lösung gefunden, mit der es mir möglich war, alle Argumente des Funktionsaufrufs an die zwei Funktionen weiterzureichen. Da es aber Javascript egal ist, mit wie vielen Parametern man eine Funktion aufruft, werden auf diese Weise bis zu 6 Übergabeparameter weitergereicht. Für Hinweise an dieser Stelle bin ich extrem dankbar.

WicketWindowJavascript

Für vieles bringt Wicket bereits fertige Implementierungen mit. Allerdings verstecken sich diese manchmal an unauffälligen Stellen. Für das Ermitteln des sichtbaren Bereichs fand ich die nötigen Javascript-Funktionen bei der ModelWindow-Klasse. Da ich nicht das vollständige ModalWindow-Javascript einbinden wollte, habe ich diese allgemeinen Funktionen in eine eigene Resource verpackt.

package de.wicketpraxis.web.blog.pages.questions.ajax.parameter;

import org.apache.wicket.ResourceReference;

public class WicketWindowJavascript
{
  private WicketWindowJavascript()
  {
  }
  
  public static final ResourceReference RESOURCE=new ResourceReference(WicketWindowJavascript.class,"WicketWindowJavascript.js");
}

// aus der Datei modal.js zur Klasse ModalWindow

if (typeof(Wicket.Window) == "undefined") {
  Wicket.Window = { };
}

/**
 * Returns the height of visible area.
 */
Wicket.Window.getViewportHeight = function() {
  if (window.innerHeight != window.undefined) 
    return window.innerHeight;
  
  if (document.compatMode == 'CSS1Compat') 
    return document.documentElement.clientHeight;
    
  if (document.body) 
    return document.body.clientHeight;
     
  return window.undefined; 
}

/**
 * Returns the width of visible area.
 */
Wicket.Window.getViewportWidth =  function() {
  if (window.innerWidth != window.undefined) 
    return window.innerWidth;
     
  if (document.compatMode == 'CSS1Compat') 
    return document.documentElement.clientWidth; 
    
  if (document.body) 
    return document.body.clientWidth;
     
  return window.undefined;
}

/**
 * Returns the horizontal scroll offset
 */
Wicket.Window.getScrollX = function() {
  var iebody = (document.compatMode && document.compatMode != "BackCompat") ? document.documentElement : document.body  
  return document.all? iebody.scrollLeft : pageXOffset
}

/**
 * Returns the vertical scroll offset
 */
Wicket.Window.getScrollY = function() {
  var iebody = (document.compatMode && document.compatMode != "BackCompat") ? document.documentElement : document.body  
  return document.all? iebody.scrollTop : pageYOffset
}


/**
 * Returns element offset
 */
Wicket.Window.getXYOffset = function(obj)
{
  var curleft = 0;
  var curtop = 0;
  if (obj.offsetParent)
  {
    while (obj.offsetParent)
    {
      curleft += obj.offsetLeft;
      curtop += obj.offsetTop;
      obj = obj.offsetParent;
    }
  }
  else
  {
    if (obj.x)
    {
      curleft += obj.x;
    }
    if (obj.y)
    {
      curtop += obj.y;
    }
  }
  
  if (Wicket.Browser.isIE())
  {
    bodyElement=document.getElementsByTagName('body')[0];
    // In IE there's a default margin in the page body. If margin's not defined,
    // use defaults
    var marginLeftExplorer  = parseInt(bodyElement.style.marginLeft);
    var marginTopExplorer   = parseInt(bodyElement.style.marginTop);
    /* assume default 10px/15px margin in explorer */
    if (isNaN(marginLeftExplorer)) {marginLeftExplorer=10;}
    if (isNaN(marginTopExplorer)) {marginTopExplorer=15;}
    curleft=curleft+marginLeftExplorer;
    curtop=curtop+marginTopExplorer;
  }

  return [curleft,curtop];
}

Hinzugefügt habe ich nur die Methode Wicket.Window.getXYOffset(), um den Offset für ein bestimmtes oder das erste Kindelement der Seite ermitteln zu können. Eine Klasse, die diese Methoden benötigt, muss die Resource entsprechend einbinden.

WindowResizeBehavior

Um die Heatmap in der richtigen Größe zeichnen zu können, benötigen wir Informationen über die Dimensionen des sichtbaren Bereichs. Für window.onresize wird ein neuer Callback registriert. Die Werte können über die ensprechend Wicket.Window-Funktionen ermittelt werden. Daher wird nicht nur der Callback registiert, sondern die Funktion nach dem Laden der Seite direkt aufgerufen. Auf diese Weise bekommen wir die Informationen über den sichtbaren Bereich nicht erst, wenn der Nutzer die Fenstergröße verändert.

package de.wicketpraxis.web.blog.pages.questions.ajax.parameter;

import org.apache.wicket.ResourceReference;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.util.time.Duration;

public abstract class WindowResizeBehavior extends AbstractParameterizedDefaultAjaxBehavior
{
  static final Parameter WIDTH=of("width", Integer.class, "Wicket.Window.getViewportWidth()");
  static final Parameter HEIGHT=of("height", Integer.class, "Wicket.Window.getViewportHeight()");

  @Override
  public void renderHead(IHeaderResponse response)
  {
    super.renderHead(response);
    response.renderJavascriptReference(WicketWindowJavascript.RESOURCE);
    response.renderOnDomReadyJavascript(getJavascript());
    response.renderOnDomReadyJavascript(getCallbackScript().toString());
  }
  
  protected final String getJavascript()
  {
    return "window.onresize = Callback.create(window.onresize,function () {"+getCallbackScript()+"});";
  }

  @Override
  protected final Parameter[] getParameter()
  {
    return new Parameter[]{ WIDTH,HEIGHT};
  }
  
  @Override
  protected void respond(AjaxRequestTarget target, ParameterMap parameterMap)
  {
    onResize(target, parameterMap.getValue(WIDTH), parameterMap.getValue(HEIGHT));    
  }
  
  protected abstract void onResize(AjaxRequestTarget target, int width, int height);
}

ElementOffsetBehavior

Die Bestimmung der richtigen Mauskoordinaten gestaltet sich insofern schwierig, als das nicht jede Webseite bei jeder Fenstergröße gleich aussieht. Damit die Koordinaten bei der Auswertung verwendbar bleiben, berechnen wir die Position in Relation zu einem Element, dass den Rahmen der Seite darstellen sollte (z.B. das erste div-Tag innerhalb des body-Tags, dass auf eine feste Breite gesetzt wurde und im sichtbaren Bereich zentriert dargestellt wird).

package de.wicketpraxis.web.blog.pages.questions.ajax.parameter;

import org.apache.wicket.ResourceReference;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.markup.html.IHeaderResponse;

import de.wicketpraxis.web.blog.pages.questions.ajax.parameter.AbstractParameterizedDefaultAjaxBehavior.Parameter;

public abstract class ElementOffsetBehavior extends AbstractParameterizedDefaultAjaxBehavior
{
  static final Parameter X_OFFSET=of("xOffset", Integer.class, "xOffset");
  static final Parameter Y_OFFSET=of("yOffset", Integer.class, "yOffset");
  
  private String _contentId;

  @Override
  public void renderHead(IHeaderResponse response)
  {
    super.renderHead(response);
    response.renderJavascriptReference(WicketWindowJavascript.RESOURCE);
    response.renderJavascriptReference(new ResourceReference(ElementOffsetBehavior.class,"ElementOffsetBehavior.js"));
    response.renderOnDomReadyJavascript(getJavascript());
  }
  
  public ElementOffsetBehavior()
  {
    
  }
  
  public ElementOffsetBehavior(String contentId)
  {
    _contentId=contentId;
  }
  
  protected final String getJavascript()
  {
    if (_contentId!=null) return "ElementOffsetBehavoir.init(function (xOffset,yOffset) {"+getCallbackScript()+"},'"+_contentId+"');";
    return "ElementOffsetBehavoir.init(function (xOffset,yOffset) {"+getCallbackScript()+"});";
  }

  @Override
  protected final Parameter[] getParameter()
  {
    return new Parameter[]{ X_OFFSET,Y_OFFSET};
  }
  
  @Override
  protected void respond(AjaxRequestTarget target, ParameterMap parameterMap)
  {
    onOffset(target, parameterMap.getValue(X_OFFSET), parameterMap.getValue(Y_OFFSET));   
  }
  
  protected abstract void onOffset(AjaxRequestTarget target, int xOffset, int yOffset);
}

Im Gegensatz zum letzten Behavior sind wir in diesem Fall auf etwas mehr Javascript angewiesen.

ElementOffsetBehavoir =
{
  init : function(callback, contentId)
  {
    function Listener(callback, contentId)
    {
      this.xOffset = 0;
      this.yOffset = 0;
      this.firstElement = null;

      // function(xOffset,yOffset)
      this.onOffsetChanged = callback;

      this.updateOffsets = function()
      {
        var offsets = Wicket.Window.getXYOffset(this.firstElement);
        this.xOffset = offsets[0];
        this.yOffset = offsets[1];
        this.onOffsetChanged(this.xOffset, this.yOffset);
      };

      var bodyElement = document.getElementsByTagName('body')[0];
      this.firstElement = bodyElement.childNodes[1];
      if (contentId != null)
      {
        this.firstElement = document.getElementById(contentId);
      }
    }

    var listener = new Listener(callback, contentId);
    listener.updateOffsets();
    window.onresize = Callback.create(window.onresize, function()
    {
      listener.updateOffsets();
    });
  }
}

Der Listener wird über die init-Methode initialisiert und wird ebenfalls aufgerufen, wenn die Fenstergröße verändert wurde. Außerdem wird die updateOffsets()-Methode bereits bei der Initialisierung aufgerufen. Somit ist auch in diesem Fall der Offset eines Elements bekannt.

PageMouseClickBehavior

Das letzte Behavior ist gleichzeitig das aufwendigste. In diesem Fall muss nicht nur die Position des Klicks ermittelt werden, sondern gleichzeitig in Relation zu einem Element gebracht werden. Auf diese Weise kommen die Koordinaten schon passend an und können z.B. auch negative Werte annehmen.

package de.wicketpraxis.web.blog.pages.questions.ajax.parameter;

import org.apache.wicket.Request;
import org.apache.wicket.ResourceReference;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.markup.html.IHeaderResponse;

public abstract class PageMouseClickBehavior extends AbstractParameterizedDefaultAjaxBehavior
{
  static final Parameter MOUSE_X=of("x", Integer.class, "x");
  static final Parameter MOUSE_Y=of("y", Integer.class, "y");
  
  String _contentId;
  
  public PageMouseClickBehavior()
  {
  }
  
  public PageMouseClickBehavior(String contentId)
  {
    _contentId=contentId;
  }
  
  @Override
  public void renderHead(IHeaderResponse response)
  {
    super.renderHead(response);
    
    response.renderJavascriptReference(WicketWindowJavascript.RESOURCE);
    response.renderJavascriptReference(new ResourceReference(PageMouseClickBehavior.class,"PageMouseClickBehavior.js"));
    response.renderOnDomReadyJavascript(getJavascript());
  }
  
  protected String getJavascript()
  {
    if (_contentId!=null) return "PageMouseClickBehavoir.init(function (x,y,xOffset,yOffset) {"+getCallbackScript()+"},'"+_contentId+"');";
    return "PageMouseClickBehavoir.init(function (x,y,xOffset,yOffset) {"+getCallbackScript()+"});";
  }

  @Override
  protected Parameter[] getParameter()
  {
    return new Parameter[] { MOUSE_X, MOUSE_Y };
  }
  
  @Override
  protected void respond(AjaxRequestTarget target, ParameterMap map)
  {
    onClick(target, map.getValue(MOUSE_X), map.getValue(MOUSE_Y));    
  }

  protected abstract void onClick(AjaxRequestTarget target, int x, int y);
}

Das dazugehörige Javascript kümmert sich um die Verarbeitung:

PageMouseClickBehavoir = 
{
  init: function(callback,contentId)
  {
    function Listener(callback,contentId)
    {
      this.xOffset=0;
      this.yOffset=0;
      this.firstElement=null;
  
      // function(x,y)
      this.onMouseEvent=callback;
      
      this.mouseEvent= function(e)
      {
        tempX=0;
        tempY=0;
        
        if (Wicket.Browser.isIE() || Wicket.Browser.isGecko())
        {
          tempX = e.clientX + Wicket.Window.getScrollX();
          tempY = e.clientY + Wicket.Window.getScrollY();
        }
        else
        {
          tempX = e.pageX
          tempY = e.pageY
        }
        tempX-=this.xOffset;
        tempY-=this.yOffset;
        this.onMouseEvent(tempX,tempY);
        return true;
      };
      
      this.updateOffsets=function()
      {
        var offsets=Wicket.Window.getXYOffset(this.firstElement);
        this.xOffset=offsets[0];
        this.yOffset=offsets[1];
      };
      
      var bodyElement=document.getElementsByTagName('body')[0];
      this.firstElement=bodyElement.childNodes[1];
      if (contentId!=null)
      {
        this.firstElement=document.getElementById(contentId);
      }
      
      this.updateOffsets();
    }
  
  
    var listener=new Listener(callback,contentId);
    
    document.onmousedown=Callback.create(document.onmousedown,function(e)
    {
      listener.mouseEvent(e)
    });
    window.onresize=Callback.create(window.onresize,function()
    {
      listener.updateOffsets();
    });
  },
}

Sobald der Nutzer klickt (auch wenn es eigentlich nichts klickbares gibt), wird eine Request an die Anwendung gesendet. Diese Behavior können wir nun in die Anwendung einbauen, um die Mausklicks der Nutzer aufzuzeichnen.

Die Anwendung

In unserer Beispielanwendung werfen wir alles in einen Topf. Wir zeichnen alle Mausklicks auf und aktualisieren dann die Heatmap.

package de.wicketpraxis.web.blog.pages.questions.ajax.parameter;

import java.awt.AlphaComposite;
import java.awt.BasicStroke;
import java.awt.Color;
import java.awt.Composite;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;

import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.image.Image;
import org.apache.wicket.markup.html.image.NonCachingImage;
import org.apache.wicket.markup.html.image.resource.DynamicImageResource;
import org.apache.wicket.markup.html.image.resource.RenderedDynamicImageResource;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.protocol.http.WebResponse;
import org.apache.wicket.util.time.Duration;

public class HeatMapPage extends WebPage
{
  List _points=new ArrayList();
  int _xOffset=0;
  int _yOffset=0;
  
  public HeatMapPage()
  {
    final FeedbackPanel feedbackPanel = new FeedbackPanel("feedback");
    feedbackPanel.setOutputMarkupId(true);
    add(feedbackPanel);

    final WebMarkupContainer box=new WebMarkupContainer("box");
    final ClickMap imageResource = new ClickMap(100, 100);
    final Image image = new NonCachingImage("map",imageResource);
    box.setOutputMarkupId(true);
    box.add(image);
    add(box);
    
    add(new ElementOffsetBehavior("#content")
    {
      @Override
      protected void onOffset(AjaxRequestTarget target, int xOffset, int yOffset)
      {
        info("Offset: "+xOffset+","+yOffset);
        _xOffset=xOffset;
        _yOffset=yOffset;
        imageResource.invalidate();
        target.addComponent(feedbackPanel);
        target.addComponent(box);
      }
    }.setThrottleDelay(Duration.milliseconds(250)));
    
    add(new PageMouseClickBehavior("#content")
    {
      @Override
      protected void onClick(AjaxRequestTarget target, int x, int y)
      {
        info("Clicked: "+x+","+y);
        _points.add(new Pos(x,y));
        imageResource.invalidate();
        target.addComponent(box);
        target.addComponent(feedbackPanel);
      }
    }.setThrottleDelay(Duration.milliseconds(50)));
    
    add(new WindowResizeBehavior()
    {
      @Override
      protected void onResize(AjaxRequestTarget target, int width, int height)
      {
        info("Size changed: "+width+","+height);
        imageResource.setWidth(width);
        imageResource.setHeight(height);
        imageResource.invalidate();
        
        target.addComponent(feedbackPanel);
        target.addComponent(box);
      }
    }.setThrottleDelay(Duration.milliseconds(250)));
    
  }
  
  class ClickMap extends RenderedDynamicImageResource
  {
    public ClickMap(int width, int height)
    {
      super(width, height,"jpg");
      setCacheable(false);
    }
    
    @Override
    protected boolean render(Graphics2D graphics)
    {
      graphics.setBackground(new Color(255,255,255));
      graphics.setColor(new Color(0,0,0,50));
      graphics.clearRect(0, 0, getWidth(), getHeight());
 
      graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
      
      for (Pos p : _points)
      {
        graphics.fillArc(_xOffset+p.getX()-5, _yOffset+p.getY()-5, 9, 9, 0, 360);
      }
      return true;
    }
  }
  
  static class Pos implements Serializable
  {
    int _x;
    int _y;
    
    public Pos(int x, int y)
    {
      super();
      _x = x;
      _y = y;
    }
    
    public int getX()
    {
      return _x;
    }
    
    public int getY()
    {
      return _y;
    }
  }
}

Im Markup müssen wir dann nur das Image hinter der Seite platzieren und schon stimmen Mausklick und Heatmap überein.


  
    Heatmap Page

In diesem Beispiel haben ich den Rahmen auf eine Breite von 800 Pixeln gesetzt und zentriert. Trotzdem werden die Mausklicks immer korrekt angezeigt.

Wie man sehen kann, ist die Interaktion von Wicket mit Ereignissen, die durch Javascript ausgelöst werden, ohne weiteres möglich. Dabei können diese Komponenten ohne weiteres in beliebigen Anwendungen benutzt werden, ohne das sich ein anderer Entwickler mit den Implementierungsdetails beschäftigen muss. Allerdings hätte ich mir gewünscht, dass die Parameterisierung von Ajax-Aufrufen bereits in den Kern von Wicket integriert wäre.

Viel Spass mit dem ausprobieren:)

Andere Beiträge

9. April 2010 -- Wicket – AbstractEvent Update
3. März 2010 -- Wicket Extensions – Anpassungen am ModalWindow
23. Dezember 2009 -- Wicket Ajax Tipp – AjaxRequestTarget nachträglich ermitteln

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("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:


  
    Nothing to hide:)
    Link

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 =
      ""+
      ""+
        ""+
          ""+                 
          ""+
        ""+
        
        ""+

        ""+
        ""+       

        ""+
        ""+

        ""+                 
        ""+

        ""+
                
        ""+
          ""+
            ""+
              ""+                                      
              
                ""+
                ""+
                  "";
        if (isFrame) {
          if (Wicket.Browser.isIELessThan7() || !Wicket.Browser.isIE()) {                       
            s+= ""+
                    "";
          } else {
            s+= ""+
            "";
          }
        } else {
          s+=
                    "";
        }
          s+=             
                  ""+
                ""+
                ""+
              ""+
            ""+
          ""+
        ""+


        ""+         
          
          ""+
          ""+
          
          ""+
          ""+

          ""+       
          ""+       


        ""+       


      ""+
    "";
    
    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("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.


  
    ModalWindow Page
  
  
    
    Open

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

Buchkritik bei it-republik.de

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

Danke für die gute Rezension.

Andere Beiträge

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