Application Builder: Grundlagen
Aus Datenbanken interne Werkzeuge und Portale mit Seiten, Elementen, Datenquellen und Ereignissen entwickeln.
In diesem Kapitel8 Abschnitte
Der Application Builder macht aus Baserow-Daten eine aufgabenbezogene Webanwendung. Statt einer großen Tabelle sehen Anwenderinnen und Anwender nur die Seiten, Informationen und Aktionen, die sie für ihren Prozess benötigen.
Für wen: Builder, Fachadministration und Prozessverantwortliche
Stand: Baserow 2.3.2, Juli 2026
Wichtig: Verfügbarkeit einzelner Elemente, Datenquellen und Authentifizierungsfunktionen hängt von Edition und Konfiguration ab.
Wann eine App sinnvoll ist
Eine App ist besonders hilfreich, wenn Personen:
- nur einen Ausschnitt der Daten sehen sollen,
- Datensätze über eine geführte Oberfläche bearbeiten,
- auf Mobilgeräten arbeiten,
- Kennzahlen und Details auf einer Seite benötigen,
- nicht mit Tabellen, Feldern und Ansichten vertraut sein müssen.
Eine App ersetzt nicht das Datenmodell. Wenn Tabellen, Beziehungen oder Zuständigkeiten unklar sind, wird auch die schönste Oberfläche unzuverlässig.
Die vier Bausteine
| Baustein | Aufgabe | Beispiel |
|---|---|---|
| Seite | URL und Layout einer Ansicht | /auftraege, /auftrag/:id |
| Element | sichtbarer oder interaktiver Baustein | Überschrift, Tabelle, Formular, Schaltfläche |
| Datenquelle | liefert Daten an Elemente | Zeilen einer Tabelle, einzelner Datensatz |
| Ereignis | reagiert auf eine Aktion | Seite öffnen, Zeile anlegen, Datensatz aktualisieren |
Zusätzlich steuern Eigenschaften, Stile, Sichtbarkeitsregeln und Variablen, wie sich diese Bausteine verhalten.
Erste Anwendung anlegen
- Öffnen Sie im Workspace den Application Builder.
- Erstellen Sie eine neue Anwendung mit einem fachlich eindeutigen Namen.
- Legen Sie zuerst die Seitenstruktur fest, etwa
Start,AufträgeundAuftragsdetail. - Verbinden Sie die benötigten Baserow-Daten als Datenquellen.
- Platzieren Sie Elemente und ordnen Sie deren Werte den Datenquellen zu.
- Verknüpfen Sie Schaltflächen und Formulare mit Ereignissen.
- Prüfen Sie die Vorschau in Desktop-, Tablet- und Mobilbreite.
- Veröffentlichen Sie erst nach einem Test mit verschiedenen Rollen.
Listen- und Detailseite als Grundmuster
Ein robustes internes Werkzeug besteht häufig aus zwei Seiten:
- Listenansicht: zeigt gefilterte Datensätze und bietet Suche oder Statusfilter.
- Detailansicht: erhält eine Zeilen-ID als Seitenparameter, lädt genau diesen Datensatz und zeigt passende Aktionen.
Prüfen Sie den Fall, dass eine ID fehlt, nicht existiert oder nicht sichtbar sein darf. Die App sollte dann eine verständliche Meldung statt leerer oder falscher Daten anzeigen.
Bearbeiten statt nur anzeigen
Für Änderungen benötigen Sie ein Eingabeelement oder Formular, passende Anfangswerte und ein Ereignis zum Aktualisieren. Legen Sie fest:
- Welche Felder dürfen geändert werden?
- Welche Werte sind Pflicht?
- Was geschieht nach erfolgreichem Speichern?
- Welche Rückmeldung erscheint bei einem Fehler?
- Muss eine Person vor einer kritischen Aktion bestätigen?
Achtung: Sichtbarkeit in der Oberfläche ist keine Sicherheitsgrenze. Eine ausgeblendete Schaltfläche ersetzt keine Berechtigung auf Datenquelle, Tabelle oder Zeile.
Vorschau und Testdaten
Nutzen Sie für den Bau eine eigene Testansicht oder Testdatenbank. Decken Sie mindestens folgende Fälle ab:
- keine Treffer,
- genau ein Datensatz,
- sehr viele Datensätze,
- lange Texte und fehlende optionale Werte,
- ungültige Eingaben,
- nicht angemeldete und unterschiedlich berechtigte Personen,
- langsame oder fehlgeschlagene Datenaktion.
Gute Reihenfolge für den Bau
- Datenmodell und Rechte klären.
- Nutzeraufgabe in einem Satz formulieren.
- Seiten und Navigationswege skizzieren.
- Datenquellen verbinden.
- Elemente und Ereignisse bauen.
- Randfälle und Rollen testen.
- veröffentlichen, beobachten und Änderungen dokumentieren.