Einführung in agorum core cards

agorum core cards verwenden Sie, wenn Sie größere Informationsmengen, etwa Suchergebnislisten, übersichtlich und flexibel darstellen möchten. agorum core cards teilt die Informationen innerhalb von Suchergebnislisten in kleinere Teile auf, die jeweils ein cardlet verwaltet. Jedes cardlet bietet diverse Funktionen zum Steuern dieser einzelnen Informationen und deren Darstellung.

Grundlage von agorum core cards ist das Widget agorum.cards.view, das die Verwaltung von cardlets übernimmt und diese auf einem darunterliegenden agorum.cardView darstellt.

Diese Dokumentation zeigt im Folgenden einen Überblick über die Funktionsweise von agorum core cards, insbesondere im Vergleich zu aguila.

Ein grundlegendes Verständnis von aguila wird vorausgesetzt.

Ähnlichkeiten mit aguila

---

Der Aufbau ist modular. Analog zu den Widgets von aguila definieren Sie cardlets, die Sie an anderer Stelle wiederverwenden können. Ein cardlet kann sich wiederum aus weiteren cardlets zusammensetzen.

Erzeugt das System eine cardlet-Instanz, ruft es einen registrierter cardlet-Handler auf, der für die Konstruktion verantwortlich ist, vergleichbar mit den Konstruktoren von aguila.

Eingebaute cardlet-Typen können Sie als Basiskomponenten verwenden (als Elemente bezeichnet).

Unterschiede zu aguila

---

Events werden jeweils vom ersten umgebenden cardlet behandelt

Das System propagiert ein Event automatisch aufwärts, ausgehend von dem cardlet, von dem es erzeugt wurde, bis es behandelt wird. Danach stoppt diese Propagierung automatisch.

• Wird ein Event von keinem cardlet-Handler behandelt, wird es stattdessen auf dem Widget agorum.cards.view ausgelöst.
• Wird ein Event von einem cardlet-Handler erzeugt, so kann es nicht von diesem selbst behandelt werden.

Wenn ein cardlet-Handler ein cardlet / Element selbst erzeugt hat (es also selbst „kennt“), ist er für die Behandlung von Events zuständig, die von diesen ausgehen. Im Gegensatz zu aguila sind hier auch cardlets voneinander isoliert, die auf demselben Element aufbauen.

Beispiel

top level: {
  type: 'sample.a',
  name: 'a'
}

cardlet sample.a: {
  type: 'sample.b',
  name: 'b'
}

cardlet sample.b: {
  type: 'agorum.vertical',
  name: 'vrt',
  items: [
    {
      type: 'sample.c',
      name: 'c1'
    },
    {
      type: 'sample.c',
      name: 'c2'
    }
  ]
}

cardlet sample.c: {
  type: 'agorum.button'
  name: 'btn',
  text: 'Test'
}

• sample.c behandelt Events, die von btn ausgehen.
• sample.b behandelt Events, die von vrt, c1 und c2 ausgehen.
• sample.a behandelt Events, die von b ausgehen und sieht insbesondere nicht Events, die von dem zugrundeliegenden cardlet vrt ausgehen.
• Events, die von a ausgehen, leitet das System als aguila-Events auf dem agorum.cards.view-Widget weiter.

Kein impliziter Kontext durch cardlet-Konstruktor

Event-Handler müssen cx.meta als expliziten Kontext verwenden, um Informationen zwischenzuspeichern. cardlet-Handler werden nur einmalig als Bibliothek eingebunden und nicht für jedes zugehörige cardlet neu erzeugt.

cardlet-Handler werden nicht im UI-Thread aufgerufen

Die Funktionen build() und event() werden außerhalb des UI-Threads aufgerufen und müssen daher etwa nicht aguila.fork() verwenden, um IO-Operationen durchzuführen. Dafür muss stattdessen umgekehrt aguila.enter() verwendet werden, um direkt auf die UI zuzugreifen (meistens nicht nötig).