App-Datenquellen, Elemente & Ereignisse
Datenquellen anbinden, Oberflächenbausteine konfigurieren und Aktionen ohne versteckte Seiteneffekte verbinden.
In diesem Kapitel8 Abschnitte
Im Application Builder entsteht Verhalten durch die Verbindung von Datenquellen, Elementen und Ereignissen. Dieser Abschnitt zeigt ein belastbares Vorgehen, bei dem jede sichtbare Information und jede Aktion nachvollziehbar bleibt.
Für wen: Personen, die Baserow-Anwendungen bauen oder abnehmen
Voraussetzung: Datenmodell, Seitenstruktur und gewünschte Rollen stehen fest
Stand: Baserow 2.3.2, Juli 2026
Datenquellen bewusst benennen
Datenquellen laden einzelne oder mehrere Datensätze und stellen sie Elementen zur Verfügung.
Geben Sie ihnen Namen wie Offene Aufträge, Aktueller Auftrag oder Angemeldete Person.
Namen wie Quelle 1 erschweren Wartung und Fehlersuche.
Prüfen Sie bei jeder Quelle:
- Welche Tabelle oder Abfrage liefert die Daten?
- Welche Filter und Sortierungen gelten?
- Stammt ein Filterwert aus URL, Element, Benutzer oder fester Vorgabe?
- Kann die Quelle leer sein?
- Muss die Menge begrenzt oder seitenweise geladen werden?
Elemente an Daten binden
Elemente können statischen Inhalt zeigen oder dynamische Werte aus einer Quelle verwenden. Typische Gruppen sind:
- Inhalt: Überschrift, Text, Bild und Trennlinie,
- Datenanzeige: Tabelle, Liste, Wiederholung oder Detailwerte,
- Eingabe: Text, Auswahl, Datum, Datei und Formular,
- Aktion und Navigation: Schaltfläche, Link, Menü,
- Layout: Spalten, Container und Abschnitte.
Die konkrete Auswahl hängt vom aktuellen Funktionsumfang ab. Bauen Sie zunächst mit wenigen, klaren Elementen. Ein wiederholter Datensatzblock sollte einen stabilen Schlüssel verwenden, nicht nur seine aktuelle Position in einer Liste.
Werte und Eigenschaften
Eine dynamische Eigenschaft kann beispielsweise den Titel des aktuellen Datensatzes, einen Seitenparameter oder den Wert eines Eingabefelds verwenden. Kontrollieren Sie jeden Ausdruck mit Testdaten und einem leeren Wert.
Praxisregel: Wenn ein Wert für Anwender entscheidungsrelevant ist, zeigen Sie seine Herkunft und Einheit verständlich an. Eine Zahl
30kann Tage, Minuten oder Euro bedeuten.
Ereignisse in kleine Schritte zerlegen
Ein Ereignis startet durch eine Interaktion oder einen Systemzustand. Häufige Auslöser sind Seite laden, Schaltfläche anklicken oder Formular absenden. Mögliche Aktionen sind Navigation, Daten anlegen, aktualisieren oder löschen und eine Meldung anzeigen.
Für einen Speichervorgang empfiehlt sich:
- Eingaben prüfen.
- Datensatz anlegen oder aktualisieren.
- Erfolg verständlich bestätigen.
- Datenquelle neu laden oder zur Detailseite navigieren.
- Fehler sichtbar behandeln, ohne interne Details preiszugeben.
Vermeiden Sie mehrere versteckte Schreibaktionen auf einer einzigen Schaltfläche. Wenn sie fachlich nötig sind, dokumentieren Sie Reihenfolge und Fehlerverhalten.
Formulare und Validierung
Markieren Sie Pflichtfelder und erläutern Sie das erwartete Format bereits vor dem Absenden. Prüfen Sie Werte zusätzlich auf Datenebene oder im nachgelagerten Prozess. Eine Prüfung nur im Browser kann umgangen werden.
Bei Dateien und Freitext gelten außerdem:
- zulässige Dateitypen und Größe begrenzen,
- keine Geheimnisse oder unnötigen personenbezogenen Daten abfragen,
- verständliche Lösch- und Aufbewahrungsregeln festlegen,
- Eingaben nicht ungeprüft als HTML ausgeben.
Sichtbarkeit, Zustand und Rollen
Elemente können abhängig von Daten, Rolle oder Anmeldestatus sichtbar sein. Planen Sie
mindestens die Zustände lädt, leer, erfolgreich und Fehler. Bei rollenabhängigen
Aktionen müssen Oberfläche und tatsächliche Datenberechtigung übereinstimmen.
| Test | Erwartung |
|---|---|
| Quelle liefert keine Zeile | Leerer Zustand mit nächstem sinnvollen Schritt |
| Schreibaktion erfolgreich | eindeutige Bestätigung, Daten aktualisiert |
| Schreibaktion fehlerhaft | verständliche Meldung, Eingaben bleiben erhalten |
| Person ohne Recht | keine Daten und keine ausführbare Aktion |
| Mobilansicht | kein abgeschnittener Inhalt, Bedienelemente erreichbar |