wicket praxis » component http://www.wicket-praxis.de/blog erfahrungen mit wicket aus dem projektalltag Fri, 26 Aug 2011 11:14:53 +0000 en hourly 1 http://wordpress.org/?v= Wicket – Flexibilität mit Factories http://www.wicket-praxis.de/blog/2010/07/15/wicket-flexibilitat-mit-factories/ http://www.wicket-praxis.de/blog/2010/07/15/wicket-flexibilitat-mit-factories/#comments Thu, 15 Jul 2010 07:13:46 +0000 michael http://www.wicket-praxis.de/blog/?p=270 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:

  1. package de.wicketpraxis.web.blog.pages.questions.factories;
  2.  
  3. import org.apache.wicket.Component;
  4.  
  5. public interface IComponentFactory<T extends Component>
  6. {
  7.   T newComponent(String id);
  8. }

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

  1. package de.wicketpraxis.web.blog.pages.questions.factories;
  2.  
  3. import org.apache.wicket.markup.html.basic.Label;
  4. import org.apache.wicket.model.IModel;
  5.  
  6. public class LabelFactory implements IComponentFactory<Label>
  7. {
  8.   IModel<?> _model;
  9.  
  10.   public LabelFactory(IModel<?> model)
  11.   {
  12.     _model = model;
  13.   }
  14.  
  15.   public Label newComponent(String id)
  16.   {
  17.     return new Label(id,_model);
  18.   }
  19. }

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.

  1. package de.wicketpraxis.web.blog.pages.questions.factories;
  2.  
  3. import org.apache.wicket.AttributeModifier;
  4. import org.apache.wicket.Component;
  5. import org.apache.wicket.behavior.AttributeAppender;
  6. import org.apache.wicket.markup.html.WebMarkupContainer;
  7. import org.apache.wicket.markup.html.panel.Panel;
  8. import org.apache.wicket.model.IModel;
  9.  
  10. public class BorderPanelFactory implements IComponentFactory<Panel>
  11. {
  12.   private final IComponentFactory<? extends Component> _content;
  13.   private final IModel<String> _style;
  14.  
  15.   public BorderPanelFactory(IComponentFactory<? extends Component> content, IModel<String> style)
  16.   {
  17.     _content = content;
  18.     _style = style;
  19.   }
  20.  
  21.   public Panel newComponent(String id)
  22.   {
  23.     return new BorderPanel(id, _content, _style);
  24.   }
  25.  
  26.   static class BorderPanel extends Panel
  27.   {
  28.     public BorderPanel(String id,IComponentFactory<? extends Component> content,IModel<String> style)
  29.     {
  30.       super(id);
  31.  
  32.       WebMarkupContainer border=new WebMarkupContainer("border");
  33.       border.add(content.newComponent("content"));
  34.       border.add(new AttributeAppender("style", true, style,";"));
  35.       add(border);
  36.     }
  37.   }
  38. }

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):
  1. <wicket:panel>
  2.   <div wicket:id="border" style="padding: 8px">
  3.     <wicket:container wicket:id="content"></wicket:container>
  4.   </div>
  5. </wicket:panel>

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

  1. package de.wicketpraxis.web.blog.pages.questions.factories;
  2.  
  3. import org.apache.wicket.markup.html.WebPage;
  4. import org.apache.wicket.model.Model;
  5.  
  6. public class ComponentFactoryPage extends WebPage
  7. {
  8.   public ComponentFactoryPage()
  9.   {
  10.     Model<String> redBorderStyle = Model.of("border:1px solid red; background-color: #fff0f0;");
  11.     Model<String> greenBorderStyle = Model.of("border:1px solid green; background-color: #f0fff0;");
  12.     Model<String> blueBorderStyle = Model.of("border:1px solid blue; background-color: #f0f0ff;");
  13.  
  14.     LabelFactory haveFunLabelFactory = new LabelFactory(Model.of("Have Fun"));
  15.  
  16.     BorderPanelFactory redBorderHasFunFactory = new BorderPanelFactory(haveFunLabelFactory,redBorderStyle);
  17.     BorderPanelFactory greenBorderWrapsRedFactory = new BorderPanelFactory(redBorderHasFunFactory,greenBorderStyle);
  18.     BorderPanelFactory blueBorderWrapsAllFactory = new BorderPanelFactory(greenBorderWrapsRedFactory,blueBorderStyle);
  19.  
  20.     add(blueBorderWrapsAllFactory.newComponent("element"));
  21.   }
  22. }

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:

  1. <html>
  2.   <head>
  3.     <title>ComponentFactory Page</title>
  4.   </head>
  5.   <body>
  6.     <wicket:container wicket:id="element"></wicket:container>
  7.   </body>
  8. </html>

Das Ergebnis sieht dann wie folgt aus:

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

  1. package de.wicketpraxis.web.blog.pages.questions.factories;
  2.  
  3. import org.apache.wicket.Component;
  4. import org.apache.wicket.markup.html.panel.Panel;
  5.  
  6. public class TwoInARowFactory implements IComponentFactory<Component>
  7. {
  8.   private final IComponentFactory<? extends Component> _left;
  9.   private final IComponentFactory<? extends Component> _right;
  10.  
  11.   public TwoInARowFactory(IComponentFactory<? extends Component> left, IComponentFactory<? extends Component> right)
  12.   {
  13.     _left = left;
  14.     _right = right;
  15.   }
  16.  
  17.   public Component newComponent(String id)
  18.   {
  19.     return new ContainerPanel(id, _left, _right);
  20.   }
  21.  
  22.   static class ContainerPanel extends Panel
  23.   {
  24.     public ContainerPanel(String id,IComponentFactory<? extends Component> left, IComponentFactory<? extends Component> right)
  25.     {
  26.       super(id);
  27.  
  28.       add(left.newComponent("left"));
  29.       add(right.newComponent("right"));
  30.     }
  31.   }
  32. }

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:
  1. <wicket:panel>
  2.   <table>
  3.     <tr>
  4.       <td><wicket:container wicket:id="left"></wicket:container></td>
  5.       <td><wicket:container wicket:id="right"></wicket:container></td>
  6.     </tr>
  7.   </table>
  8. </wicket:panel>

Unsere Seitenklasse ergänzen wir entsprechend:

  1. package de.wicketpraxis.web.blog.pages.questions.factories;
  2.  
  3. import org.apache.wicket.markup.html.WebPage;
  4. import org.apache.wicket.model.Model;
  5.  
  6. public class ComponentFactoryPage extends WebPage
  7. {
  8.   public ComponentFactoryPage()
  9.   {
  10.     Model<String> redBorderStyle = Model.of("border:1px solid red; background-color: #fff0f0;");
  11.     Model<String> greenBorderStyle = Model.of("border:1px solid green; background-color: #f0fff0;");
  12.     Model<String> blueBorderStyle = Model.of("border:1px solid blue; background-color: #f0f0ff;");
  13.  
  14.     LabelFactory haveFunLabelFactory = new LabelFactory(Model.of("Have Fun"));
  15.  
  16.     BorderPanelFactory redBorderHasFunFactory = new BorderPanelFactory(haveFunLabelFactory,redBorderStyle);
  17.     BorderPanelFactory greenBorderWrapsRedFactory = new BorderPanelFactory(redBorderHasFunFactory,greenBorderStyle);
  18.     BorderPanelFactory blueBorderWrapsAllFactory = new BorderPanelFactory(greenBorderWrapsRedFactory,blueBorderStyle);
  19.  
  20.     add(blueBorderWrapsAllFactory.newComponent("element"));
  21.  
  22.     TwoInARowFactory twoInARowFactory = new TwoInARowFactory(redBorderHasFunFactory, greenBorderWrapsRedFactory);
  23.  
  24.     add(twoInARowFactory.newComponent("two"));
  25.   }
  26. }

Das Markup muss ebenfalls angepasst werden:

  1. <html>
  2.   <head>
  3.     <title>ComponentFactory Page</title>
  4.   </head>
  5.   <body>
  6.     <wicket:container wicket:id="element"></wicket:container>
  7.     <wicket:container wicket:id="two"></wicket:container>
  8.   </body>
  9. </html>

Das Ergebnis kann sich sehen lassen:

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

Gibt es noch ganz andere Lösungsstrategien?

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Andere Beiträge

]]> http://www.wicket-praxis.de/blog/2010/07/15/wicket-flexibilitat-mit-factories/feed/ 4 Wicket – lose Koppelung von Komponenten http://www.wicket-praxis.de/blog/2010/01/05/wicket-lose-koppelung-von-komponenten/ http://www.wicket-praxis.de/blog/2010/01/05/wicket-lose-koppelung-von-komponenten/#comments Tue, 05 Jan 2010 08:02:40 +0000 michael http://www.wicket-praxis.de/blog/?p=225 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.

  1. package de.wicketpraxis.web.blog.pages.questions.events;
  2.  
  3. public interface EventListenerInterface
  4. {
  5.   public void notifyAjaxEvent(AbstractEvent event);
  6. }

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

  1. package de.wicketpraxis.web.blog.pages.questions.events;
  2.  
  3. import org.apache.wicket.Component;
  4. import org.apache.wicket.Page;
  5. import org.apache.wicket.Component.IVisitor;
  6. import org.apache.wicket.ajax.AjaxRequestTarget;
  7.  
  8. public class AbstractEvent
  9. {
  10.   Component _source;
  11.   AjaxRequestTarget _requestTarget;
  12.  
  13.   protected AbstractEvent(Component source,AjaxRequestTarget requestTarget)
  14.   {
  15.     _source=source;
  16.     _requestTarget=requestTarget;
  17.   }
  18.  
  19.   public Component getSource()
  20.   {
  21.     return _source;
  22.   }
  23.  
  24.   public void fire()
  25.   {
  26.     Page page = _source.getPage();
  27.     if (page instanceof EventListenerInterface)
  28.     {
  29.       ((EventListenerInterface) page).notifyAjaxEvent(this);
  30.     }
  31.     page.visitChildren(EventListenerInterface.class, new AjaxEventVisitor(this));
  32.   }
  33.  
  34.   public void update(Component component)
  35.   {
  36.     if (_requestTarget!=null) _requestTarget.addComponent(component);
  37.   }
  38.  
  39.   protected static class AjaxEventVisitor implements IVisitor<Component>
  40.   {
  41.     AbstractEvent _event;
  42.  
  43.     protected AjaxEventVisitor(AbstractEvent event)
  44.     {
  45.       _event=event;
  46.     }
  47.  
  48.     public Object component(Component component)
  49.     {
  50.       ((EventListenerInterface) component).notifyAjaxEvent(_event);
  51.       return IVisitor.CONTINUE_TRAVERSAL;
  52.     }
  53.   }
  54. }

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.

  1. package de.wicketpraxis.web.blog.pages.questions.events;
  2.  
  3. import org.apache.wicket.Component;
  4. import org.apache.wicket.ajax.AjaxRequestTarget;
  5.  
  6. public class ChangeEvent extends AbstractEvent
  7. {
  8.   int _change;
  9.  
  10.   protected ChangeEvent(Component source, AjaxRequestTarget requestTarget, int change)
  11.   {
  12.     super(source, requestTarget);
  13.  
  14.     _change=change;
  15.   }
  16.  
  17.   public int getChange()
  18.   {
  19.     return _change;
  20.   }
  21. }

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

  1. package de.wicketpraxis.web.blog.pages.questions.events;
  2.  
  3. import org.apache.wicket.markup.html.basic.Label;
  4. import org.apache.wicket.markup.html.panel.Panel;
  5. import org.apache.wicket.model.IModel;
  6.  
  7. public class CounterPanel extends Panel implements EventListenerInterface
  8. {
  9.   IModel<Integer> _counter;
  10.  
  11.   public CounterPanel(String id,IModel<Integer> counter)
  12.   {
  13.     super(id);
  14.  
  15.     setOutputMarkupId(true);
  16.  
  17.     _counter=counter;
  18.  
  19.     add(new Label("counter",_counter));
  20.   }
  21.  
  22.   public void notifyAjaxEvent(AbstractEvent event)
  23.   {
  24.     if (event instanceof ChangeEvent)
  25.     {
  26.       int change = ((ChangeEvent) event).getChange();
  27.       Integer cur = _counter.getObject();
  28.  
  29.       info("Aktuell: "+cur+" Change: "+change);
  30.  
  31.       _counter.setObject(cur+change);
  32.       event.update(this);
  33.     }
  34.   }
  35. }

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

  1. <wicket:panel>
  2.   <span wicket:id="counter"></span>
  3. </wicket:panel>

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

  1. package de.wicketpraxis.web.blog.pages.questions.events;
  2.  
  3. import org.apache.wicket.ajax.AjaxRequestTarget;
  4. import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
  5. import org.apache.wicket.markup.html.basic.Label;
  6. import org.apache.wicket.markup.html.panel.Panel;
  7. import org.apache.wicket.model.IModel;
  8.  
  9. public class ActionPanel extends Panel
  10. {
  11.   public ActionPanel(String id,IModel<Integer> change)
  12.   {
  13.     super(id);
  14.  
  15.     AjaxFallbackLink<Integer> link = new AjaxFallbackLink<Integer>("link",change)
  16.     {
  17.       @Override
  18.       public void onClick(AjaxRequestTarget target)
  19.       {
  20.         new ChangeEvent(ActionPanel.this,target,getModelObject()).fire();
  21.       }
  22.     };
  23.     link.add(new Label("change",change));
  24.     add(link);
  25.   }
  26. }

  1. <wicket:panel>
  2.   <a wicket:id="link"><span wicket:id="change"></span></a>
  3. </wicket:panel>

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

  1. package de.wicketpraxis.web.blog.pages.questions.events;
  2.  
  3. import org.apache.wicket.markup.html.WebPage;
  4. import org.apache.wicket.markup.html.panel.FeedbackPanel;
  5. import org.apache.wicket.model.Model;
  6.  
  7. public class EventPage extends WebPage
  8. {
  9.   public EventPage()
  10.   {
  11.     add(new EventFeedbackPanel("feedback"));
  12.  
  13.     add(new ActionPanel("changeAdd1",Model.of(1)));
  14.     add(new ActionPanel("changeSub1",Model.of(-1)));
  15.  
  16.     add(new CounterPanel("counter",Model.of(5)));
  17.   }
  18.  
  19.   static class EventFeedbackPanel extends FeedbackPanel implements EventListenerInterface
  20.   {
  21.     public EventFeedbackPanel(String id)
  22.     {
  23.       super(id);
  24.  
  25.       setOutputMarkupId(true);
  26.     }
  27.  
  28.     public void notifyAjaxEvent(AbstractEvent event)
  29.     {
  30.       event.update(this);
  31.     }
  32.   }
  33. }

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

  1. <html>
  2.   <head>
  3.     <title>EventPage</title>
  4.   </head>
  5.   <body>
  6.     <div wicket:id="feedback"></div>
  7.  
  8.     <wicket:container wicket:id="changeAdd1"></wicket:container>
  9.     <wicket:container wicket:id="changeSub1"></wicket:container>
  10.  
  11.     <div wicket:id="counter"></div>
  12.   </body>
  13. </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:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Andere Beiträge

]]> http://www.wicket-praxis.de/blog/2010/01/05/wicket-lose-koppelung-von-komponenten/feed/ 0 Wicket Komponentenübersicht http://www.wicket-praxis.de/blog/2009/10/16/wicket-component-overview/ http://www.wicket-praxis.de/blog/2009/10/16/wicket-component-overview/#comments Fri, 16 Oct 2009 06:57:45 +0000 michael http://www.wicket-praxis.de/blog/?p=166 Ich habe in den letzten Tagen damit angefangen, die verschiedenen Componenten, die Wicket bereits in dem Basisbibliotheken bietet, zu visualisieren. Den ersten Versuch habe ich noch von Hand durchgeführt, um schnell festzustellen, dass man auf diese Weise nicht besonders schnell vorwärts kommt. Der zweite und damit aktuelle Ansatz ist da schon sehr viel versprechend. Es werden die Wicket-Quellen geparst und alle Klassendefinitionen eingelesen, die Abhängigkeiten untereinander ermittelt, verschiedene Filter angewendet um die Darstellung auf ein Thema einzugrenzen und das ganze dann mit dem dot-Programm aus dem Graphviz-Paket in ein Diagramm umgewandelt.

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

Wicket Kompontenten - Basis

Wicket Kompontenten – Basis

Wicket Komponenten inklusive Extensions

Wicket Komponenten inklusive Extensions

Wicket Modelle

Wicket Modelle

Wicket Behavior

Wicket Behavior

Wicket Listener

Wicket Listener

Wicket RequestTarget

Wicket RequestTarget

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Andere Beiträge

]]> http://www.wicket-praxis.de/blog/2009/10/16/wicket-component-overview/feed/ 2