App-Datenquellen, Elemente & Ereignisse
Datenquellen anbinden, Oberflächenbausteine konfigurieren und Aktionen ohne versteckte Seiteneffekte verbinden.
In diesem Kapitel11 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: Dokumentationsstand siehe Stand-Zeile oben auf dieser Seite
Datenquellen bewusst benennen
Datenquellen laden einzelne oder mehrere Datensätze und stellen sie Elementen zur Verfügung.
Geben Sie ihnen Namen wie Offene Verkaufschancen, Aktueller Kontakt 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 |
Abnahme-Check
CRM-Beispiel: Kontaktliste und Detailseite
Binden Sie eine Tabellenkomponente auf /kontakte an die Datenquelle Kontakte. Zeigen
Sie Name, Unternehmen und Wiedervorlage. Ein Link öffnet /kontakt/:id mit der stabilen
Zeilen-ID des ausgewählten Kontakts, nicht mit seiner Position in der Liste.
Die Detailseite lädt genau diese Zeile über Aktueller Kontakt. Ein Eingabefeld kann den
nächsten Rückruftermin erfassen. Die Schaltfläche Wiedervorlage speichern aktualisiert
nur dieses Datumsfeld, lädt die Datenquelle neu und meldet Erfolg oder Fehler. Prüfen Sie
anschließend dieselbe Zeile im Database Builder.
Testen Sie außerdem eine fehlende ID, eine gelöschte Zeile und einen Zugriff ohne passende Berechtigung. Die Änderung einer URL darf keinen fremden Kontakt zugänglich machen.
Typische Fehler
Eine Zeilenposition ist keine stabile ID. Prüfen Sie eine manipulierte URL und einen fehlgeschlagenen Schreibvorgang ebenso wie den Erfolgsfall.
Weiter mit
Die App prüfen und veröffentlichen.
