Modelle, Binden an Eigenschaften

Model I

• Ein Model erledigt für Wicket den Zugriff auf Daten- bzw. Modellobjekte.

• Wird abgebildet durch das Interface IModel:

  public interface IModel {
  
      public Object getObject();
      public void setObject(final Object object);
  
  }

Model II

• Komponenten können mit einem Model erzeugt werden:

  add(new Label("message", new Model("Hello World!")));

• Häufig gibt es zusätzliche Konstruktoren, die das Modell intern erzeugen:

  add(new Label("message", "Hello World!"));

• Zugriff auf das Modell(objekt) einer Komponente erfolgt mit:

  void setDefaultModel(final IModel<?> model)
  void setDefaultModelObject(final Object object)
  IModel<?> getDefaultModel()
  Object getDefaultModelObject()

PropertyModel

• PropertyModel ermittelt den Wert für eine Komponente durch Ausführung einer Expression, z.B.:

  // Bedeutungsgleich zu: new Model(carObject.getVendor().getName());
  // Zusätzlich: Verweis auf Objekt-Eigenschaft, null-Behandlung
  new PropertyModel(carObject, "vendor.name")

CompoundPropertyModel I

• Ein CompoundPropertyModel stellt automatisch Modelle für beinhaltete Komponenten bereit:

  public SomePage() {
      super(new CompoundPropertyModel<Car>(someCarObject);
      add(new Label("name"));
      add(new Label("vendor.name"));
  }

• Im obigen Beispiel haben die Labels kein eigenes Modell: Es wird daher das Modell der Parent-Komponente verwendet (CompoundPropertyModel), welches die Eigenschaften anhand der Komponenten-ID auflöst:

  

CompoundPropertyModel II

• Eigenschaften können auch explizit (unabhängig von der Komponenten-ID) gebunden werden:

  add(new Label("vendor", someCompoundPropertyModel.bind("vendor.name")));

• Objekteigenschaften sollten bevorzugt mit CompoundPropertyModel gebunden werden, da so die Eigenschaften des Modellobjektes nicht nur einmalig zugewiesen werden, sondern dynamisch gebunden sind. Insbesondere kann so das Modellobjekt beliebig ausgetauscht und aktualisiert werden.

Detachable Models

• Modelle werden mit den Seitenobjekten in der Session abgelegt und werden daher u.U. persistiert: Modellobjekte müssen serialisierbar sein.
• Häufig können Modellobjekte unproblematisch wiederbeschafft werden und müssen nicht persistiert werden. Dies wird über detachable models erreicht: Modelle können ihre Daten verwerfen, nachdem die Seite fertig gerendert wurde.

Beispiel LoadableDetachableModel

    public class CarModel extends LoadableDetachableModel<Car> {

        private final int id;
    
        public CarModel(int id) {
            this.id = id;
        }
    
        @Override
        protected Car load() {
            return CarRepository.loadCar(id);
        }
    
    }

Verkettung von Modellen

• Modelle können verkettet werden, um z.B. die Eigenschaften eines Objektes, welches dynamisch geladen wird, mit einem CompoundPropertyModel zu binden:

  new CompoundPropertyModel(new CarModel(carId));

CompoundPropertyModel in ListViews: PropertyListView

• Wicket stellt die Klasse PropertyListView bereit, bei der die Listen-Einträge automatisch per CompoundPropertyModel je Zeile gebunden werden:

  PropertyListView<Car> listView = new PropertyListView<Car>("cars", carList) {
  
      @Override
      protected void populateItem(ListItem<Car> item) {
          item.add(new Label("name"));
          item.add(new Label("vendor.name"));
      }
  
  };

Umgang mit serialVersionUID I

• Anhand der serialVersionUID einer Klasse wird entschieden, ob eine serialisierte Objektrepräsentation kompatibel zur aktuellen Version der Klasse ist.

• Erfolgt keine explizite Angabe, wird eine serialVersionUID aus der Signatur der Klasse berechnet (kann sich auch ändern, wenn die Klasse noch kompatibel wäre).

• Standardmäßig erfolgt eine Warnung "The serializable class does not declare a static final serialVersionUID field of type long" bei fehlender serialVersionUID.

• Die serialVersionUID kann mit Quick Fix (Ctrl + 1) in Eclipse ergänzt werden:

  private static final long serialVersionUID = 1L;

Umgang mit serialVersionUID II

• Vergabe einer serialVersionUID kann dabei helfen, Sessions nach einer Aktualisierung der Anwendung gültig zu halten.
• Zwingend notwendig ist die Angabe nur, wenn eine Anwendung über verschiedene JVMs geclustert wird (Berechnung der serialVersionUID ist plattformabhängig).
• Alternativ können die Warnungen mit der Annotation @SuppressWarnings("serial") lokal unterdrückt werden.
• Alternativ können die Warnungen in den Projekteinstellungen unter Java Compiler > Errors/Warnings > Potential programming problems > Serializable class without serialVersionUID deaktiviert werden.

Weitere Informationen

• Working with Wicket models http://cwiki.apache.org/WICKET/working-with-wicket-models.html
• Wicket in Action: 4. Understanding models