P5.js: Problem gelöst, Wurzelverzeichnis gefunden

Für mein gestriges Problem, wo denn in Dreiteufelsnamen ein eingebetteter P5.js-Sketch seine root, sein Wurzelverzeichnis vermutet, habe ich die Antwort gefunden. Denn manchmal lohnt es sich tatsächlich, in die Dokumentation zu schauen. Denn dort steht nämlich klar und deutlich: »The path to the image should be relative to the HTML file that links in your sketch.«

Also ist die root für relative Pfade nicht – wie ich vermutet hatte – der Speicherort des Sketches, sondern die URL der HTML-Datei, in die der Sketch eingebettet ist. In meinem Fall bedeutet das also, daß der relative Pfad nicht mit (zum Beispiel)

bg = loadImage("../images/background.jpg");

aufgerufen wird, sondern stattdessen

bg = loadImage("images/background.jpg");

heißt. Daß die Bilder bei mir nicht im Verzeichnis des Skripts, sondern im Verzeichnis der HTML-Datei eine Ebene höher liegen, ist unter anderem einer Eigenschaft des ERB-Makros (ERB: Embedded Ruby) imageref() von RubyFrontier geschuldet. Das sucht nämlich rekursiv im Verzeichnis der aufgerufenen Datei und darüber nach einem Folder #images, aber nicht in Verzeichnissen, die unterhalb liegen. Und da das gleiche für das Makro linkjavascripts() gilt, das analog nach einem Verzeichnis #javascripts sucht, bleibt mir keine andere Wahl, als die Bilder getrennt von dem Sketch abzulegen.

Das sieht zuerst einmal unbequem und ungewohnt aus, aber wie das Beispiel oben zeigt, vereinfacht es das Anlegen relativer Links. Matt Neuburg hatte sich beim Design von RubyFrontier schon etwas gedacht. Danke, Matt. 🤓

Und wer jetzt ob der Erläuterungen verwirrt aus der Wäsche guckt, dem sei gesagt, daß – nach der Intention von Matt Neuburg – RubyFrontier ein Werkzeug für erfahrene Programmierer und nicht für Warmduscher ist.

Aber ich kann jetzt endlich wüst und hemmungslos mein Blog Kritzelheft mit sinnbefreiten P5.js-Sketchen vollkritzeln. Ich freue mich schon darauf. Still digging!

(Kommentieren)