Nicht immer ist es möglich oder sinnvoll, im Konstruktor einer Komponente bereits die vollständige Komponentenstruktur anzulegen. Wie man Komponenten zu einem späteren Zeitpunkt anlegen kann, kann man in den Repeater-Klassen ansehen. Aber es geht wesentlich einfacher. Nach dem Erstellen einer Komponente wird als nächstes (für den Fall,dass die Komponente dargestellt wird) onBeforeRender() aufgerufen. Wir können die fehlenden Komponenten in diesem Methodenaufruf erstellen. Wir müssen nur darauf achten, dass diese Initialisierung nur einmal durchgeführt wird. Am besten verpacken wir das ganze in eine eigene Klasse.
| 01 | package de.wicketpraxis.web.blog.pages.questions.lazy; |
| 02 | |
| 03 | import org.apache.wicket.markup.html.panel.Panel; |
| 04 | |
| 05 | public abstract class AbstractLazyPanel extends Panel |
| 06 | { |
| 07 | boolean _lazyInitCalled; |
| 08 | |
| 09 | public AbstractLazyPanel(String id) |
| 10 | { |
| 11 | super(id); |
| 12 | } |
| 13 | |
| 14 | @Override |
| 15 | protected void onBeforeRender() |
| 16 | { |
| 17 | if (!_lazyInitCalled) |
| 18 | { |
| 19 | _lazyInitCalled=true; |
| 20 | lazyInit(); |
| 21 | } |
| 22 | super.onBeforeRender(); |
| 23 | } |
| 24 | |
| 25 | protected abstract void lazyInit(); |
| 26 | } |
Eigene Komponenten werden dann von dieser Klasse abgeleitet. Dieser Umbau hat keine Veränderung des Markup zur Folge, da keinerlei Hilfskomponenten eingefügt wurden.
| 01 | package de.wicketpraxis.web.blog.pages.questions.lazy; |
| 02 | |
| 03 | import org.apache.wicket.markup.html.basic.Label; |
| 04 | import org.apache.wicket.model.Model; |
| 05 | |
| 06 | public class TestPanel extends AbstractLazyPanel |
| 07 | { |
| 08 | public TestPanel(String id) |
| 09 | { |
| 10 | super(id); |
| 11 | } |
| 12 | |
| 13 | @Override |
| 14 | protected void lazyInit() |
| 15 | { |
| 16 | add(new Label("label",Model.of("Label"))); |
| 17 | add(new SimplePanel("panel")); |
| 18 | } |
| 19 | } |
| 1 | <wicket:panel> |
| 2 | <span wicket:id="label"></span> |
| 3 | <br> |
| 4 | <wicket:container wicket:id="panel"></wicket:container> |
| 5 | </wicket:panel> |
Wie man sieht, lässt sich die neuen Klasse sehr einfach als Ersatz für die Panel-Klasse benutzen. Vielleicht ist dieser Ansatz ausbaufähig, so dass man durch eine verspätete Initialisierung auch die Probleme rund um TransparentResolver umgehen kann.
Andere Beiträge
Posted in Allgemein, Refactoring, Wicket.
Tagged with init, lazy, transparent resolver, Wicket.
By michael
– 20. Januar 2010
Interessanter Beitrag. Wir benutzen diese Methode häufiger.
> Wir müssen nur darauf achten, dass diese Initialisierung nur einmal durchgeführt wird
Als Variante kann man in onBeforeRender() auch zunächst alle Kind-Komponenten entfernen (removeAll()) und danach wieder neu erzeugen lassen, so dass die Kind-Komponenten bei jedem Rendern neu erzeugt werden. Dadurch erhält man quasi ein “AbstractRefreshingPanel”, analog zu einer RefreshingView.
Man sollte den if noch ein synchronized spendieren:
synchronized (this) {
if (!_lazyInitCalled)
{
_lazyInitCalled=true;
lazyInit();
}
super.onBeforeRender();
}
das liefert wicket alleine:
public void onBeforeRender() {
if(!hasBeenRendered()) {
// initialize
}
super.onBeforeRender();
}
AFAIK werden die Komponenten dann aber erst initialisiert, wenn die Elternkomponente auch sichtbar ist…. aber sonst, ja, geht auch so.
will man das denn vorher?
Es ist nicht auszuschließen.. wenn man z.B. über Events auch unsichtbare Komponenten erreichen möchte.. in der Palette-Komponente (wicket extensions) gab es mal einen Bug, der auf so eine Problemstellung zurückzuführen war..
das stimmt.
Ich habe mir den sourcecode von Component noch mal näher angeschaut und glaube, dass man sich doch nicht auf hasBeenRendered verlassen sollte, das der Zustandswechsel dort von vielen Randbedingungen abhängt.