wicket praxis » admin

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.

Andere Beiträge

No Related Post

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<Component> 
{
  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<Component> 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 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.

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

Migration zu Wicket: Ajax

admin — Tue, 15 Sep 2009 06:29:17 +0000

Einer der Aspekte, die bei meiner Entscheidung für ein neues Webframework eine große Rolle spielten, war die Integration von Ajax. Fast jedes aktuelle Framework bietet eine Unterstützung von Ajax, doch unterscheiden sie sich in Handhabung und Möglichkeit.

Die komponentenorientierte Arbeitsweise von Wicket führt dazu, dass eine Wicket-Seite (die Entsprechung einer Webseite), aus einem Komponentenbaum besteht, bei der jede Komponente für ihre Darstellung verantwortlich ist. Daher ist es besonders einfach, den Teil zu identifizieren, der durch die jeweilige Komponente dargestellt wird. Diesen Umstand macht sich Wicket zu nutze, um im Gegensatz zu anderen Frameworks, beliebig viele Bereiche der Webseite aktualisieren zu können.

Im folgenden Beispiel soll das veranschaulicht werden:

package de.wicketpraxis.web.blog.pages.migration.ajax;
 
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.Model;
 
public class AjaxMultiUpdatePage extends WebPage
{
  public AjaxMultiUpdatePage()
  {
    final FeedbackPanel feedback=new FeedbackPanel("feedback");
    feedback.setOutputMarkupId(true);
    add(feedback);
 
    // die geschweiften Klammern haben keine Funktion
    // sie sollen nur den Komponentenbaum veranschaulichen
    WebMarkupContainer block = getBlock(feedback,1);
    {
      WebMarkupContainer block2 = getBlock(feedback,2);
      {
        WebMarkupContainer block3 = getBlock(feedback,3);
        block2.add(block3);
      }
      block.add(block2);
    }
    add(block);
  }
 
  private WebMarkupContainer getBlock(final FeedbackPanel feedback, int start)
  {
    final WebMarkupContainer block = new WebMarkupContainer("ajaxUpdate");
    block.setOutputMarkupId(true);
 
    Model<Integer> model = Model.of(start);
    final Label label = new Label("count",model);
    label.setOutputMarkupId(true);
    block.add(label);
 
    block.add(new AjaxFallbackLink<Integer>("link",model)
    {
      @Override
      public void onClick(AjaxRequestTarget target)
      {
        setModelObject(getModelObject()+1);
        info("Aktualisiere "+getPath());
        if (target!=null)
        {
          target.addComponent(feedback);
          target.addComponent(block);
 
          // ist nicht nötig
          target.addComponent(label);
        }
      }
    });
 
    return block;
  }
}

Wir fügen der Seite ein FeedbackPanel hinzu. Für jede Komponente, die per Ajax aktualisiert werden soll, muss die setOutputMarkupId(true) aufgerufen werden. Dass veranlasst Wicket, in dem Html-Tag dieser Komponente das id-Attribut zu setzen. Das ist notwendig, damit Wicket diesen Tag dann durch neuen Inhalt ersetzen kann.

Als weiteres erzeugen wir einen WebMarkupContainer. Dieses Element dient uns als Rahmen, um die Aktualisierung des ganzen Blocks anstoßen zu können. Als Kindelemente definieren wir zusätzlich ein Label, das den Inhalt eines Modells darstellt, dass wir gleichzeitig in einem AjaxFallbackLink benutzen. Klickt der Nutzer auf den Link, wird der Wert im Modell erhöht und der Block sowie das FeedbackPanel in die Liste der zu aktualisierenden Komponenten aufgenommen. Auch das Label wurde zu dieser Liste hinzugefügt. Allerdings kommt hier bereits eine Optimierung zum Vorschein, die Wicket vornehmen kann, da der Komponentenbaum bekannt ist: Wicket ersetzt den ganzen Block und weiß, dass damit auch das Label aktualisiert wurde, weshalb es nicht gesondert ersetzt werden muss.

Innerhalb eines Blockes fügen wir einen weiteren als Kindelement ein. Das wiederholen wir noch einmal. Wird in dieser Konstellation nun der äußere Block aktualisiert, werden auch alle Kindelemente aktualisiert. Dieses Verhalten kann man überprüfen, in dem man die Kommunikation im WicketAjaxDebug-Fenster betrachtet.

Wicket Ajax Debug Window

Deaktiviert man JavaScript und damit Ajax, dann funktioniert die Seite trotzdem, da dann die ganze Seite neu gerendert wird. Auf diese Weise kann man Webanwendungen mit Ajax-Unterstützung entwickeln, ohne dass man Nutzer, die aus welchen Gründen auch immer JavaScript deaktiviert haben, im Regen stehen lässt.

<html>
  <head>
    <title>AjaxMultiUpdate</title>
    <style type="text/css">
      .block
      {
        border:1px solid dashed;
      }
    </style>
  </head>
  <body>
    <h1>Ajax Test</h1>
    <div wicket:id="feedback"></div>
 
    <div wicket:id="ajaxUpdate" class="block">
      <span wicket:id="count">123</span> <a wicket:id="link">+1</a>
      <div wicket:id="ajaxUpdate" class="block">
        <span wicket:id="count">123</span> <a wicket:id="link">+1</a>
        <div wicket:id="ajaxUpdate" class="block">
          <span wicket:id="count">123</span> <a wicket:id="link">+1</a>
 
        </div>
      </div>
    </div>
  </body>
</html>

Dieses Beispiel offenbart wesentliche Unterschiede zwischen der Ajax-Integration von Wicket und anderen Frameworks:

Wicket kann beliebig viele Komponenten innerhalb eines Request aktualisieren.
Wicket kann die Aktualisierung optimieren.
Auch bei deaktiviertem Javascript ist die Funktion der Anwendung gewährleistet.

Andere Beiträge

21. Juli 2009 -- Grails Ajax Update zu kompliziert…
9. April 2010 -- Wicket – AbstractEvent Update
7. März 2010 -- Wicket Heatmap – Ajax mit Parametern

Update

admin — Mon, 14 Sep 2009 07:27:33 +0000

Eine neue Version des Beispielcodes zum Buch steht unter Download zur Verfügung. Außerdem ist der Code zu den Beispielen im Blog enthalten und können so einfach ausprobiert werden.

Andere Beiträge

No Related Post

Quelltext der Beispiele aus dem Buch zum Download

admin — Thu, 03 Sep 2009 21:39:03 +0000

Ich habe gerade die Beispiele aus dem Buch zum einem Paket geschnürt. Dieses kann man sich auf der Download-Seite herunterladen und ausprobieren. Alles weitere steht auf der Seite.

Das Quelltextarchiv wird in den nächsten Tagen auch auf der Verlagsseite zum Buch Praxisbuch Wicket zu finden sein.

Andere Beiträge

7. Juli 2009 -- Scala kommt
27. Mai 2009 -- Wicket Praxis als Buch
29. April 2011 -- Wicket – Back Button zuverlässig erkennen

Scala vs Java

admin — Wed, 26 Aug 2009 07:52:10 +0000

Ich habe mir gestern ein Scala-Codebeispiel angesehen, dass Scala-Objekte von und nach JSON konvertieren kann. Ich muss zugeben, dass es ein wenig gedauert hat, bis ich den Code verstanden habe. Das liegt unter anderem daran, dass ich in Scala einfach noch nicht gut genug bin. Der andere wichtigere Punkt ist aber folgender:

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

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

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

Andere Beiträge

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

Wicket Migration von 1.3.5 auf 1.4-rc2

admin — Mon, 02 Mar 2009 13:52:14 +0000

Soeben habe ich eine Migration auf Wicket 1.4-rc2 durchgeführt. Ausschlaggebend für die Migration war die Überarbeitung im Model-Bereich. Typisierte Modelle sind sehr viel handlicher und machen den Code sehr viel lesbarer. Da man die Komponenten ja auch schon generisch angelegt hat, ging diese Information bisher in den Modellen verloren.

Interessante Statistik:

Anzahl der Java-Dateien im Webprojekt: 376
Anzahl der Java-Dateien, die angepasst werden mussten: 32
Zeitaufwand für die Umstellung: 1h,30min

Ich glaube, das Risiko ist gering und der Vorteil ist groß. Meine Empfehlung: Umsteigen.

Andere Beiträge

19. Juni 2009 -- Wicket und Scala – der Rückweg ist anstrengend
29. April 2011 -- Wicket – Back Button zuverlässig erkennen
24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB

Wicket Resourcen mit Jetty nachladen

admin — Wed, 31 Dec 2008 14:56:32 +0000

Bei großen Wicket-Projekten kann das hotdeployment des maven jetty plugins schonmal dazu führen, dass aus dem Vorteil ein Nachteil wird. Dabei ist das Ziel recht einfach: Nur die Html-Templates für die Wicket-Komponenten sollen neu geladen werden, wenn sich da was verändert hat. Alle Vorschläge aus den Foren sind mir zu aufwendig Außerdem mag ich die Html-Dateien nicht in das selbe Verzeichnis wie die Quelltexte legen. Ich habe mir daher einen für das Problem angepassten ResourceStreamLocator geschrieben:

public class MavenDevResourceStreamLocator extends ResourceStreamLocator
{
  String _prefix="src/main/resources/";
 
  public IResourceStream locate(final Class clazz, final String path)
  {
    IResourceStream located=getFileSysResourceStream(path);
    if (located != null)
    {
      // alles ok
      return located;
    }
    // fallback
    located=super.locate(clazz, path);
    return located;
  }
 
  private IResourceStream getFileSysResourceStream(String path)
  {
    File f=new File(_prefix+path);
    if ((f.exists()) && (f.isFile()))
    {
      return new FileResourceStream(f);
    }
    return null;
  }
}

Eingebaut wird das dann in die init-Methode der Application-Klasse wie folgt:

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

Und schon werden alle Änderungen an den Html-Dateien sichtbar.

Andere Beiträge

27. Oktober 2009 -- Wicket Tipps: Markup
29. April 2011 -- Wicket – Back Button zuverlässig erkennen
24. Oktober 2010 -- Wicket – Mainstream, Github, MongoDB