Ohne Server-Code geht's gar nicht

[Rolf B]

Hallo Jochen,

die Version siehst Du in der URL, bei jedem Update geht der Zähler eins hoch.

FileAPI habe ich selbst noch nicht benutzt, es dient aber dazu, Dinge auf der Maschine des Anwenders zu speichern, nicht auf dem Server. Entspricht das deinen Zielen?

Wenn Du die Anzahl der Bilder/Videos erhöhen oder verringern willst, ohne zu löschen, dann musst Du den Eventhandler etwas anders programmieren. Du musst zuerst prüfen, ob Du die Anzahl der Upload-Elemente erhöhen oder verringern musst (oder ob sie gleichbleibt, dann tust Du gar nichts). Wenn erhöhen, dann füge solange Elemente hinzu bis die Anzahl stimmt. Wenn verringern, dann entferne solange das letzte Element bis die Anzahl stimmt. Aber was machst Du, wenn Du die Bilder 3-5 behalten willst? Dann funktioniert das nicht mehr, dann sind die Anzahl-Dropdowns ein Irrweg. Deswegen sollte man, bevor man zu programmieren beginnt, eine Vision haben, wie das Gesamtsystem ausieht, oder zumindest ein minimal lebensfähiges Produkt (minimal viable product, MVP) im Auge haben. Und sich über alle Operationen im Klaren sein, die man da ausführen will. Und sich ständig fragen: Gibt mein UI her, was ich tun will?

Das Thema der Speicherung taucht dabei dann auch immer wieder auf. Die Namensvergabe für Ressourcen ist nur ein Teil. Ein KLEINER. Du bist auf dem Weg zu einem CRUD-System - nein Scherz, das steht für "Create, Read, Update, Delete", also die klassischen Operationen eines Systems zur Datenpflege. Aus Sicht eines Programmierers immer der gleiche Dreck...

Bisher haben wir nur über das C nachgedacht. Du kannst was anlegen, und irgendwann speichern. Du möchtest am nächsten Tag aber den Browser aufmachen und die gespeicherten Dinge wieder sehen. Du möchtest, dass Änderungen geändert bleiben und Löschungen gelöscht. Sowas setzt identifizierende Merkmale voraus. Identifizierend heißt: Es bleibt unveränderlich erhalten. Wenn Du einen Arbeitsplatz neu anlegst, braucht eine eine eindeutige ID. Wenn ein Bild hinzukommt, braucht es eine eindeutige ID. Ein Video auch. Wenn Du einen Arbeitsplatz löschst, wird seine ID nicht wiederverwendet, und die von ihm abhängigen Ressourcen (Bilder, Videos) müssen ebenfalls gelöscht werden. Wenn ein Bild/ein Video eine eindeutige ID hat, kannst du das Bild korrekt aus der Liste herauslöschen. Sonst nicht, bzw. löschst eventuell irgendwas, aber nicht das, was der User will.

Wenn Du ein serverloses System denkst, das mit File API arbeitet, machst Du das alles lokal im JavaScript und auf deiner Maschine, und hast das Problem konkurrierender Zugriffe nicht. Wenn Du mit einem Webserver arbeitest, dann übernimmt normalerweise der Server die Ablage und Organisation der Daten und Dateien. Und zwar eigenständig, auf Grund eines in PHP, Perl, Ruby, C#, Java oder sonstwie geschriebenen Programms (oder auch mit JavaScript, wenn Du node.js als Server nimmst, das ist aber deswegen nicht leichter). Vom Client aus die Ablage auf dem Server zu steuern, ihn also sozusagen nur als ferne Festplatte zu nutzen, mag mit HTTP Befehlen wie PUT und DELETE machbar sein, das muss aber entsprechend eingerichtet sein. Und vor allem kommt dann die Frage auf: Was ist, wenn zwei Leute die Anwendung gleichzeitig verwenden? PL hat das Ölkännchen gezückt und ist davongeflutscht, als ich diese Details seines Vorschlags herauslocken wollte. Aus gutem Grund. Da stecken nämlich viele Tretminen.

Tja. Worauf will ich eigentlich hinaus? Ich möchte Dich dazu zwingen, den "kein serverseitiger Code" Ansatz sehr gut zu durchdenken. Diese Entscheidung hat gravierende Konsequenzen. Und ob dich durch ein Projekt, das dahin läuft, per Forenberatung hindurchbegleiten MÖCHTE, das weiß ich nicht recht. Der Aufwand wird jetzt schon sehr groß. Einige Teile der Lernkurve musst Du selbst erklimmen. Bei Detailproblemen kann man Dir helfen. Aber nicht bei jedem einzelnen Schritt.

Rolf