Direkt zum Hauptinhalt

Besucher Änderungen speichern lassen

Ziel​

Jemand in Ihrem Portal soll eine Anfrage stellen, ändern oder löschen können – nicht nur lesen.

Bevor Sie beginnen​

  • Ein Portal, bei dem Wer es öffnen kann auf Angemeldete Personen eingestellt ist. In einem Portal, das jeder öffnen kann, wird Schreiben abgelehnt: Es gäbe niemanden, dem die Änderung zugeordnet werden könnte. Siehe Besucher zur Anmeldung auffordern.
  • Eine benutzerdefinierte API für jede Aktion, die Besucher ausführen dürfen. Eine, die liest, ist keine, die schreibt, und die Plattform behandelt sie nicht als beides.

Schritte​

  1. Schreiben Sie die Custom API. Zum Anlegen machen Sie ihr Verb zu POST, zum Ändern zu PATCH, zum Löschen zu DELETE. Schreiben Sie ein Anfrageschema dafür: Es steht als Erstes zwischen einem Besucher und einer Spalte, die er nicht setzen soll. Ohne eines darf der Anfragetext eines Besuchers nur die Felder tragen, die Ihr Skript mit getInput liest; alles andere wird abgelehnt.
  2. Öffnen Sie Ihre Lösung, wählen Sie Portale aus und öffnen Sie das Portal.
  3. Drücken Sie unter Was es lesen kann auf Lesequelle hinzufügen und wählen Sie:
    • die Tabelle, die Ihr Bildschirm in createRecord / updateRecord / deleteRecord nennt,
    • die Operation – Datensatz anlegen, Datensatz ändern oder Datensatz löschen,
    • die API, die sie beantwortet.
  4. Drücken Sie Speichern.

Jede der fünf Aktionen, die ein Bildschirm ausführen kann, braucht eine eigene Zeile. Ein Portal, das Anfragen auflisten kann, kann erst dann eine anlegen, wenn Sie auch die Zeile zum Anlegen hinzufügen – das sind zwei getrennte Verträge, und die Seite kann nur die Tabelle nennen.

Was Ihr Bildschirm tut​

Nichts Neues. Dieselben Aktionen, die Sie für eine App innerhalb der Plattform zeichnen würden:

createRecord("par_request", {
  par_name: getState("subject"),
  par_detail: getState("detail")
}, "saved");

In einem Portal wird daraus ein Aufruf der API, die Sie für par_request / Datensatz anlegen freigegeben haben. Die Zeichnung bleibt unverändert – genau darum geht es, wenn man eine App an zwei Orten veröffentlicht.

Was die API tun muss​

Entscheiden, wer das tun darf, und ausfüllen, was der Besucher nicht darf.

var me = portalEmail();
if (me == '') {
  throwValidationError('Sign in before raising a request.');
} else {
  var subject = getInput('par_name');
  if (subject == '') {
    throwValidationError('Please give your request a subject.');
  } else {
    // **The visitor does not get to say who raised it.** Whatever the page sent for this column
    // is ignored; the address comes off their signed-in session.
    var id = createRecord('par_request', {
      par_name: subject,
      par_detail: getInput('par_detail'),
      par_raised_by_email: me,
      par_status: 'New'
    });
    setOutput('record', getRecord('par_request', id));
  }
}

Einen Besucher aus den Spalten heraushalten, die er nicht setzen soll​

Das Portal leitet den Body genau so weiter, wie die Seite ihn gesendet hat, und anders kann es nicht: Welche Felder ein Besucher setzen darf, ist eine Frage über Ihre Tabelle, und nur Ihr Vertrag kennt die Antwort.

Zwei Dinge beantworten sie, und Sie wollen beide.

Ihr Anfrageschema, das ein Feld ablehnt, das Sie nie zugesagt haben. Setzen Sie "additionalProperties": false und führen Sie nur auf, was ein Besucher senden darf:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["par_name"],
  "properties": {
    "par_name": { "type": "string", "minLength": 1, "maxLength": 200 }
  }
}

Ein Body mit par_raised_by_email wird jetzt abgelehnt, bevor Ihr Skript läuft.

Jedes Feld beim Namen lesen, wie es das Skript oben tut. getInput('par_name') nimmt, wonach Sie gefragt haben, und nichts sonst.

Reichen Sie den Body nie komplett weiter

Ein Skript, das den ganzen Body an createRecord übergibt, lässt einen Besucher jede Spalte setzen, deren Namen er erraten kann – einschließlich derjenigen, die sagt, wem der Datensatz gehört. Das Schema macht das schwer; das Lesen beim Namen macht es unmöglich.

Was der Besucher sieht, wenn es fehlschlägt​

  • Eine Ablehnung, die Sie geschrieben haben – throwValidationError('Please give your request a subject.') – erscheint neben der Schaltfläche, die er gedrückt hat.
  • Alles andere zeigt ein allgemeines „Das konnte nicht gespeichert werden“, und der eigentliche Grund geht in das Protokoll des Portal-Hosts.

Diese Trennung ist Absicht: Ihr Satz betrifft ihn, und er kann danach handeln, während ein interner Fehler weder das eine noch das andere ist.

Ihre Validierungsmeldungen lesen Fremde

Weil die erste Art angezeigt wird, schreiben Sie diese Sätze für die Öffentlichkeit. Nennen Sie keine Spalte, keine Tabelle und keine interne Regel – „Bitte geben Sie Ihrer Anfrage einen Betreff“ statt „par_name failed constraint NOT NULL“.

Was die Plattform nicht prüft​

Ob ein Besucher zurücklesen kann, was er gerade geschrieben hat. Wenn Ihre API zum Anlegen einen Datensatz speichert, den Ihre Abfrage-API herausfiltert, existiert der Datensatz, und die Liste zeigt ihn nicht. Nichts warnt Sie: Die beiden Skripte sind getrennte Verträge, und die Plattform stellt ein Paar, das Sie mit Absicht so geschrieben haben, nicht infrage.

Wenn ein Bildschirm etwas speichert und dann eine leere Liste anzeigt, liegt es meist daran – vergleichen Sie den Filter in Ihrer Lese-API mit dem, was Ihre Schreib-API gespeichert hat.

Es wieder ausschalten​

Entfernen Sie die Zeile aus Was es lesen kann, oder stellen Sie Wer es öffnen kann zurück auf Jeder. Beides beendet das Schreiben des Portals sofort. Das Zweite beendet es auch in dem Moment, in dem Sie speichern, obwohl die Zeilen noch aufgeführt sind – ein offenes Portal bedient seine Lesevorgänge und keinen seiner Schreibvorgänge.

Verwandte Seiten​