Direkt zum Hauptinhalt

Eine Ansicht als Raster anzeigen

Ziel​

Eine Liste von Datensätzen in Ihr Portal bringen, ohne die Liste zu zeichnen – das eigene Raster der Plattform, mit den Spalten, die eine Ansicht festlegt.

Bevor Sie beginnen​

  • Eine Ansicht der Tabelle mit den Spalten, die Besucher sehen sollen. Von hier kommen die Überschriften, die Breiten und die Reihenfolge.
  • Eine benutzerdefinierte API, die die Tabelle auflistet und unter Was es lesen kann des Portals angehakt ist. Wie diese Liste funktioniert, lesen Sie unter Eine App als Portal veröffentlichen.

Schritte​

  1. Ziehen Sie im App-Designer Komponenten → Tabellenansicht oder Formular dorthin, wo die Liste hin soll.
  2. Wählen Sie auf der Registerkarte Bildschirm die Tabelle. Lassen Sie Ansicht auf Standard der Tabelle, oder wählen Sie eine der Ansichten der Tabelle.
  3. Wählen Sie unter Benutzerdefinierte API (Portal) den Vertrag, über den die Zeilen kommen – etwa Notices (api:par_list_notices@1). Angeboten werden nur Verträge, die auf GET antworten, denn ein Raster liest nur.
  4. Veröffentlichen Sie, und öffnen Sie das Portal.

Mehr ist auf der Seite der Zeichnung nicht zu tun. Spalten wählen Sie hier nicht aus – das hat die Ansicht schon getan.

Ein Raster stellt zwei Fragen, und die beiden Felder beantworten je eine. Die Tabelle und die Ansicht entscheiden, was angezeigt wird – die Überschriften, die Breiten, die Reihenfolge –, und die Plattform ermittelt das, bevor die Seite ausgeliefert wird, sodass nichts über die Struktur Ihrer Tabelle einen öffentlichen Browser erreicht. Die benutzerdefinierte API entscheidet, welche Zeilen, denn in einem Portal geht jeder Lesevorgang über einen Vertrag, den Sie geschrieben haben. In der App-Liste wird das API-Feld ignoriert, und die Tabelle liefert beides.

Was die API tun muss​

Seitenweise liefern und sagen, wie viele es gibt. Das Raster fragt jeweils eine Seite ab und liest total, um zu wissen, ob es eine nächste gibt:

var page = runQuery({
  entity: 'par_notice',
  select: ['par_name', 'par_category', 'par_published_on'],
  order: [{ field: 'par_published_on', descending: true }],
  top: num(getInput('top')),
  skip: num(getInput('skip'))
});

setOutput('rows', page);
setOutput('total', page.length());

Ohne total kann die Seitennavigation eine letzte Seite nicht von einer vollen unterscheiden und bietet ein Weiter an, das ins Leere führt.

Eine Spalte, die die Ansicht hat und die API nicht liefert​

Sie zeigt in jeder Zeile einen Strich. Die Ansicht bestimmt die Überschriften; die API bestimmt, was in jeder Zeile steht, und ein Feld, das ihr select weglässt, steht nicht in der Zeile. Eine Spalte hinzuzufügen sind also zwei Änderungen: die Spalte in der Ansicht und das Feld im select der API.

Das ist Absicht und kein Versehen. Die Ansicht wird mit der App in der Plattform geteilt, und eine Spalte, die Sie dort für Ihre eigenen Leute hinzufügen, soll dieses Feld nicht für Fremde veröffentlichen. Was die Plattform verlässt, ist, was die API auswählt.

Ein Raster ohne API erscheint überhaupt nicht​

Lassen Sie Benutzerdefinierte API (Portal) leer oder nennen Sie eine, die das Portal nicht bekommen hat, und das Raster wird nicht ausgeliefert – Sie erhalten gar kein Raster statt Überschriften über einem leeren Inhalt.

Das ist Absicht, und es ist dieselbe Regel, die der Rest des Portals befolgt: Ein leeres Raster liest sich als es gibt keine Datensätze, und das ist eine andere Aussage als dieses Portal durfte sie nie anzeigen. Auf das direkte Lesen der Tabelle zurückzufallen wäre noch schlimmer – es wäre genau die Tür, die §6.11.3 schließt, nur über einen anderen Weg.

Woher die Spalten kommen, und wann​

Aus der Ansicht, wenn das Portal ausgeliefert wird. Bearbeiten Sie die Ansicht, laden Sie das Portal neu, und die Spalten ändern sich – es muss nichts erneut veröffentlicht werden. Deshalb fragt eine Portalseite die Plattform auch nie, was eine Ansicht enthält: Die Antwort kommt mit der Seite.

Wenn Sie eine Ansicht nennen und sie später löschen, meldet das Raster, dass es nicht verfügbar ist, statt stillschweigend auf die Standardansicht zurückzufallen. Sie haben diese Spalten gewählt, und eine andere Auswahl, die ohne Warnung auf einer öffentlichen Seite erscheint, ist schlimmer als ein Raster, das ehrlich sagt, dass es defekt ist.

Was ein Besucher damit tun kann und was nicht​

Er kann es lesen und darin blättern. Er kann keine Zeilen auswählen, keinen Datensatz öffnen und keine Befehlsleiste verwenden – nichts davon gibt es hier. Jede dieser Aktionen betrifft einen Datensatz, und was ein Fremder mit einem Datensatz tun darf, entscheidet Ihre benutzerdefinierte API, nicht ein Raster.

Soll ein Besucher etwas tun können, zeichnen Sie eine Schaltfläche und geben Sie ihr eine eigene Zeile in der Freigabeliste.

In einem Portal nicht verfügbar​

  • Ein Schnellformular (Create/Edit-Oberflächen). Ein Formular braucht die Pflichtregeln der Tabelle, ihre Auswahlwerte und ihre Plug-in-Schritte, und nichts davon gehört auf eine öffentliche Website. Zeichnen Sie stattdessen die Felder, und schreiben Sie die benutzerdefinierte API hinter Ihrer Schaltfläche „Speichern“ – siehe Besucher Änderungen speichern lassen.
  • Eine Aufgabenliste. Ein Portalbesucher ist kein Plattformbenutzer und hat keinen Posteingang.

Beides wird auf der Seite gemeldet, statt stillschweigend zu scheitern.

Prüfen, ob es funktioniert hat​

Öffnen Sie das Portal so, wie ein Fremder es tun würde. Das Raster zeigt die Spalten Ihrer Ansicht, mit deren Überschriften, und blättert durch die Datensätze, die die API zurückgibt. Bearbeiten Sie dann eine der Spaltenüberschriften der Ansicht und laden Sie neu – das Portal zieht nach.