Axure Repeater – den Kontext von Aktionen verstehen und foreach-Schleifen umsetzen

Der so genannte Repeater ist ein neues Widget in Axure RP 7, welches erlaubt, strukturierte Daten zu verwalten und in sich wiederholender Form auszugeben. Beispiele sind etwa Tabellen oder die Produkte auf einer Übersichtsseite im Online-Shop: Jedes Produkt wird auf die gleiche Art und Weise angezeigt, etwa mit Bild, Titel und Preis, nur die zugrunde liegenden Daten variieren. Mit dem Repeater-Widget lässt sich eine solche Darstellung leicht umsetzen und zudem mit Interaktivität versehen. Denn es können ganz einfach Sortier- und FIlterfunktionen umgesetzt werden.

Repeater sind sehr mächtige Werkzeuge, aber leider auch nicht ganz einfach zu verstehen. Denn die Dokumentation seitens Axure ist recht mangelhaft. Deshalb habe ich mich selber daran gemacht, die Details der Funktionsweise herauszufinden. Heute erkläre ich zwei Aspekte, die mir selber sehr weitergeholfen haben, um Repeater effizient einzusetzen:

  • Der Kontext von Aktionen: Wann wirkt sich eine Aktion auf alle Elemente eines Repeaters aus, wann nur auf einzelne?
  • Foreach-Schleifen: Wie führt man eine bestimmte Aktion für jedes Element eines Repeaters einzeln durch?

Der Beispiel-Prototyp

Während meiner eigenen Experimente habe ich einen kleinen Prototyp erstellt, den ich auch in diesem Beitrag zur Erläuterung einsetzen will (siehe Abb. 1).

Axure-Prototyp mit Repeater

Abb. 1: Erläuterungen zum Beispiel-Prototyp

Abruf über AxShare: http://axshare.eresult.de/B9JIWG/repeater-loop.html

Download der RP-Datei: https://www.usabilityblog.de/wp-content/uploads/2014/09/RepeaterLoop_JP.rp

Der Kontext von Aktionen in Bezug auf einen Repeater

Ohne Repeater verhält es sich in Axure sehr einfach mit Aktionen: Jedes Element im Prototyp existiert nur einmal und hat einen Namen, über den es angesteuert werden kann, um etwa den Text darauf zu modifizieren.

Aber durch Repeater wird es komplizierter: Jedes Element im Repeater gibt es mehrmals, nämlich so oft wie der Repeater Einträge hat. In einer Produktübersicht etwa gibt es für jedes Produkt ein Bild – aber das Bild-Element heißt immer gleich! Wie verhält es sich dann, wenn man dieses Element ansteuert, also etwa den Text darauf modifiziert?

Das Verhalten in diesem Fall kommt darauf an, von wo aus die Aktion angestoßen wird – ich nenne dies den Kontext der Aktion. Es können zwei unterschiedliche Kontexte unterschieden werden:

  • Innerhalb des Repeaters: Wenn das Event, welches die Aktion auslöst, selber innerhalb des Repeaters liegt, so wird die Aktion nur für das eine Element des Repeaters ausgeführt, welches im selben Repeater-Eintrag liegt.
    Beispiel: Wenn sich bei Mouseover über dem Produkttext eine Aktion ausgeführt wird, die das Bild ändert, so ändert sich nur das Bild des einen Produktes, zu dem der Produkttext gehört, über dem der Mouseover ausgeführt wird.
  • Außerhalb des Repeaters: Wenn das Event, welches die Aktion auslöst, nicht selber in dem Repeater liegt, so wird die Aktion für das angesprochene Element in allen sichtbaren Repeater-Einträgen durchgeführt.
    Beispiel: Wenn außerhalb der eigentlichen Produktliste ein Schalter für das Umschalten der Bilder zwischen Vorder- und Rückansicht ist, so wird beim Betätigen jedes Bild im Repeater umgeschaltet.

Im Beispiel-Prototypen zeigen sich diese Kontexte an folgender Stelle: Mit einem Klick auf ein Repeater-Item lässt sich der Selected-Status des Elements ändern. Zudem gibt es einen Button „Invert Selection“, der für alle Repeater-Items den Selected-Status umschaltet. Der Clou: Die Aktion ist in beiden Fällen exakt identisch: „Set is selected of Item to toggle“. Nur durch den unterschiedlichen Kontext wird einmal nur ein Element angesprochen und einmal alle Elemente.

Wenn man sich diese Funktionsweise vor Augen führt, scheint sie eigentlich sehr intuitiv und macht Sinn. Man muss sich aber auch der Konsequenzen bewusst sein: Man kann nicht ohne weiteres…

  • … alle Einträge eines Repeaters von einem Element innerhalb des Repeaters aus ansprechen.
  • … einen spezifischen Eintrag eines Repeaters von außen ansprechen.

Dafür müssen die entsprechenden Aktionen zunächst über ein anderes Element geleitet werden, welches im richtigen Kontext liegt. Dazu später im Rahmen der foreach-Schleife mehr.

Der Kontext von Abfragen in Bezug auf einen Repeater

Ebenfalls wichtig zu wissen: Der Kontext gilt nicht nur für den Effekt von Aktionen. Auch die Abfrage von Eigenschaften (etwa dem Text auf einem Element) erfolgt in Abhängigkeit vom Kontext. Dabei gelten folgende Regeln:

  • Eine Abfrage aus einem Repeater hat den Kontext des selben Repeater-Eintrags. Die Abfrage wird also auf das entsprechende Element im selben Repeater-Eintrag bezogen.
  • Eine Abfrage von außerhalb hat den Kontext des ersten sichtbaren Repeater-Eintrags. Die Abfrage wird also auf das entsprechende Element im ersten sichtbaren Repeater-Eintrag bezogen.

Die foreach-Schleife durch einen Repeater

Die Programmierer unter uns kennen den Begriff der foreach-Schleife: Eine Datenstruktur (in diesem Fall der Repeater) wird Eintrag für Eintrag durchgegangen und für jeden Eintrag wird eine Aktion (oder mehrere) durchgeführt.

Für einen komplexen Prototypen mit Repeater ist solch eine Schleife unersetzlich. Ich habe schon während der Beta-Phase von Axure RP 7 eine Art foreach-Schleife verwendet, damals allerdings noch unter Verwendung des OnLoad-Events und durch ein manuelles Neuladen des Repeaters – sie funktionierte, war aber kompliziert und nicht besonders performant.

Mit dem gewonnenen Verständnis für den Kontext von Aktionen und Abfragen lässt sich eine foreach-Schleife sehr viel eleganter umsetzen. Der Schlüssel liegt im Delegieren von Aktionen von einem Element außerhalb des Repeaters an Elemente innerhalb des Repeaters. Die Grundidee des Delegierens von Aktionen nutze ich auch für das Umsetzen von Funktionen in Axure: Ein Event eines Elements stößt die Aktion eines anderen Elementes an, welche wiederum ein Event dieses Elements auslöst. Dieses zweite Event kann dann den delegierten Code ausführen.

Der Ansatz für eine foreach-Schleife ist also wie folgt:

  1. Ein Element (z. B. der Button) außerhalb des Repeaters stößt eine Aktion für ein Element innerhalb des Repeaters an. Durch den Kontext wird diese Aktion für jede Instanz dieses Elementes ausgeführt, also einmal pro Repeater-EIntrag. Ich nutze hierfür die Move-Aktion.
  2. Die Aktion (Move) löst ein Event bei jedem einzelnen Element aus (OnMove). Die Reihenfolge der ausgelösten Events entspricht dabei der Reihenfolge der Einträge im Repeater: Zuerst für den ersten Eintrag, dann für den zweiten usw.
  3. An diesem Event (OnMove) kann beliebiger Code angehängt werden, der innerhalb des Repeater-Kontextes agieren kann.

Deutlicher wird dieses Prinzip sicherlich am konkreten Beispiel des Prototypen. Hier habe ich eine foreach-Schleife umgesetzt, die die Anzahl der markierten Einträge im Repeater zählt und ausgibt. Das funktioniert so:

  1. Der Button „CountSelectedButton“ bewegt beim Klick das Element „fCountSelected“ innerhalb des Repeaters. Dieses Element ist unsichtbar und dient nur für die Umsetzung der Schleife.
  2. Am OnMove-Event des Elements „fCountSelected“ hängen eine Reihe von Aktionen (siehe Abb. 2):
  3. Zunächst wird geprüft, ob wir gerade beim ersten Eintrag des Repeaters sind. Die unter dieser Bedingung ausgeführten Aktionen passieren nur einmal und quasi vor der eigentlichen Schleife. Hier setze ich die Variable mit dem Zähler auf 0 zurück.
  4. Dann folgt die eigentliche Schleife: Für alle Fälle, in denen „Item“ ausgewählt ist, wird der Zähler um 1 erhöht.
  5. Zuletzt wird geprüft, ob wir gerade beim letzten Eintrag des Repeaters sind. Jetzt kann noch etwas nach der eigentlichen Schleife ausgeführt werden. In diesem Fall wird hier das Ergebnis der Zählung per Javascript-Alert ausgegeben.
Foreach-Schleife in einem Repeater

Abb. 2: Das OnMove-Event des Repeater-Elements, welches die Schleife ausführt

Auf diese Art lassen sich auch einzelne Einträge des Repeaters von außen ansteuern: Indem die Bedingung für die foreach-Schleife so gesetzt wird, dass nur das gewünschte Element angesprochen wird.

Fazit: Repeater sind unerlässlich für komplexe Prototypen

Die Erläuterungen zum Kontext und den mit diesem Wissen möglichen Dingen wie foreach-Schleifen zeigen: Das Repeater Widget ist ebenso mächtig wie es kompliziert ist. Mit dem nötigen Verständnis für die genaue Funktionsweise lassen sich sehr komplexe Prototypen umsetzen, die realistisch ganze Online Shops oder Anwendungen mit Datentabellen simulieren.

Genauso wie die Funktionen in Axure ist aber auch diese foreach-Schleife eigentlich ein Hack und unnötig kompliziert. Ich bin gespannt, wann Axure solche Dinge von Haus aus unterstützt…

Haben Sie auch schon Erfahrungen mit dem Repeater-Widget sammeln können? Haben sie vielleicht eigene Tipps und Tricks dazu? Gerne beantworte ich auch Ihre Fragen in den Kommentaren.

Portraitfoto: Jan Pohlmann

Jan Pohlmann

UX Designer

BMW AG

Bisher veröffentlichte Beiträge: 60

Ein Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.