Ich wollte es einfach mal ausprobieren.
Ob man in FileMaker einen kleinen visuellen Editor bauen kann – mit Knoten, Linien, Verbindungen, Drag & Drop.
Nichts Großes. Nur um zu sehen, ob das überhaupt reagiert.
Also habe ich einen WebViewer genommen, ein paar Zeilen JavaScript reingeschmissen und angefangen, mit JSON zwischen den beiden Welten zu funken.
Und siehe da: FileMaker hat brav mitgespielt.
Der Moment, als die erste Verbindung sichtbar wurde, war schon ziemlich cool.
Du ziehst eine Linie von einem Node zum nächsten, und im Hintergrund feuert FileMaker ein Script ab.
Dann klickst du sie wieder weg – und das System reagiert.
Das war der Punkt, an dem ich dachte: Okay, das ist nicht mehr nur eine Idee. Das funktioniert wirklich.
Ab da fing mein Kopf an zu rattern.
Was, wenn das nicht nur ein kleiner Proof of Concept ist,
sondern der Anfang von etwas, das den Umgang mit FileMaker verändert?
Nicht im großen, revolutionären Sinn, sondern auf eine ganz stille, einfache Art:
indem man plötzlich sehen kann, was man sonst nur in Skripten liest.
Ich meine – wir verbringen Stunden in Script Workspaces, klicken, kopieren, testen,
und verlieren irgendwann den Überblick, wenn die Logik komplex wird.
Mit einem visuellen Editor dagegen sieht man die Struktur, die Abhängigkeiten, den Fluss.
Man klickt, zieht, verbindet – und FileMaker denkt mit.
Das war das erste Mal, dass ich das Gefühl hatte,
FileMaker könnte sich auch wie ein moderner Workflow-Builder anfühlen,
nicht nur wie ein klassisches Datenbanksystem mit Scripts.
Was daraus werden könnte
Ab diesem Punkt wurde es spannend.
Ich habe angefangen, mir vorzustellen, was man damit machen könnte,
wenn man die Idee ernst nimmt.
Stell dir einen visuellen Workflow-Editor direkt in FileMaker vor.
Kein externer Dienst, keine Cloud, kein fremdes Tool –
ein integrierter Raum, in dem du Prozesse visuell modellieren kannst.
Ein Node „Get Contacts“, ein Node „Filter by City“, ein Node „Send Email“.
Du ziehst sie auf die Fläche, verbindest sie, und FileMaker führt das im Hintergrund aus.
Plötzlich ist der Script Workspace nicht mehr nur eine Zeilenliste,
sondern eine Art Canvas –
eine Denkfläche, auf der man Logik, Datenfluss und Aktionen sehen und begreifen kann.
Das ist kein Ersatz für Code – aber eine neue, visuelle Sprache,
die FileMaker wieder zugänglich macht für Leute,
die lieber sehen als lesen.
Und dann kam der Gedanke:
Was wäre, wenn jeder Entwickler eigene Nodes definieren könnte?
Kleine Bausteine – vielleicht API-Integrationen, kleine Tools,
Funktionen für Logging, E-Mail, JSON-Parsing oder Machine Learning.
Wenn diese Nodes teilbar wären, könnte sich daraus ein Marktplatz entwickeln.
Ein Raum, in dem FileMaker-Entwickler ihre Arbeit miteinander teilen –
nicht als Plugin oder Add-on, sondern als visuelle Komponente.
Das wäre nicht Make oder n8n in neuem Gewand,
sondern ein dezentrales, leichtes System für FileMaker selbst.
Jeder könnte einsteigen, ohne Hosting, ohne Docker, ohne neue Plattform.
Einfach importieren, verbinden, laufen lassen.
Realistische Weiterentwicklung
Aber um dahin zu kommen, braucht es Grundlagen.
Und da kommt der nerdige Teil, der mich ehrlich gesagt am meisten reizt:
Wie kriegt man es hin, dass FileMaker wirklich versteht, was da passiert?
Wie wird aus einem hübschen Node eine echte Script-Logik?
Die Antwort liegt im Script-Mapping.
Wir arbeiten schon länger daran, FileMaker-Skripte in eine JSON-Struktur zu übersetzen.
Das heißt: jeder Script-Step – von Set Variable über Go to Layout bis Perform Script –
wird als eigenes JSON-Objekt mit klaren Parametern abgebildet.
Diese Objekte kommen direkt aus der XML-Repräsentation,
die FileMaker intern für Skripte verwendet.
Ziel ist es, die XML-Syntax aufzubrechen
und in ein offenes, lesbares Format zu bringen,
das sich leicht parsen, speichern und visualisieren lässt.
Und ja – das ist Fleißarbeit.
Denn es gibt keine universelle Parametrisierung,
keine geheime Formel, die automatisch alle Script-Schritte übersetzt.
Man muss das bestehende Set an Steps einmal durchgehen,
jeden analysieren, seine Parameter erfassen und das Mapping sauber definieren.
Aber der Aufwand ist endlich.
Wenn man das einmal gemacht hat,
steht das Gerüst.
FileMaker bringt pro Release vielleicht ein paar neue Steps dazu –
das ist kaum Aufwand, das nachzupflegen.
Und sobald das Mapping steht,
wird jeder originale FileMaker-Script-Step automatisch als Node im Editor verfügbar.
„Set Field“ wird ein Node mit Eingangs- und Ausgangsport.
„If“ wird ein Conditional-Node.
„Perform Script“ bekommt Parameter.
Und jeder Node bleibt im vertrauten Kontext –
es ist immer noch dein FileMaker, nur eben greifbarer.
Das bedeutet:
Der visuelle Editor ist kein Fremdkörper.
Er ist die andere Ansicht derselben Logik.
Ein zweiter Blick auf dieselbe Maschine.
Text oder Fläche – beides greift ineinander.
Das ist das eigentlich Schöne:
Man muss nichts Neues erfinden.
Man muss nur sichtbar machen, was längst da ist.
Eine Einladung zum Mitdenken
Und genau da, glaube ich, liegt das Potenzial.
Weil das kein Riesenprojekt eines Konzerns sein muss,
sondern etwas, das aus der Community wachsen kann.
Jeder, der Lust hat, könnte sich ein Stück rauspicken:
einen Script-Step dokumentieren, ihn als JSON definieren, testen, teilen.
Das ist keine hohe Einstiegshürde – nur ein bisschen Zeit, Neugier und Präzision.
Wenn genug Leute das tun, entsteht über die Monate hinweg ein vollständiges Mapping,
ein lebendes Vokabular aller FileMaker-Script-Schritte.
Das Schöne daran ist:
Es ist nicht nur nützlich für den Editor,
sondern auch als Referenz.
Man könnte sich damit ganze Skripte generieren, vergleichen, analysieren,
Scripting-Engines aufbauen, Versionierungen dokumentieren.
FileMaker würde dadurch – zum ersten Mal überhaupt –
eine maschinenlesbare Programmiersprache bekommen,
ohne seinen Charakter zu verlieren.
Und dann kommen wir an den Punkt,
an dem der FMVisualNodeEditor nicht mehr nur ein Editor ist,
sondern eine Darstellungsform einer Idee:
dass FileMaker eine visuelle, geteilte Sprache werden kann.
Warum das zu FileMaker passt
FileMaker war schon immer visuell.
Layouts, Tabellen, Beziehungen – alles grafisch.
Nur der Script Workspace blieb lange Zeit textbasiert.
Vielleicht ist das hier die logische Fortsetzung der FileMaker-Philosophie:
ein Werkzeug, das Dinge so zeigt, wie sie gedacht werden.
Wenn man ehrlich ist,
hat FileMaker alle nötigen Bausteine längst an Bord.
Der WebViewer bringt moderne Browser-Technologie.
JSON ist die universelle Sprache zwischen Front- und Backend.
Perform Script in Web Viewer und FileMaker.PerformScript() bilden die Brücke.
Das ist keine Science-Fiction – das ist jetzt schon da.
Und wenn man das Ganze noch mit ein paar netten UI-Details versieht –
Zoom, Pan, Snap-Lines, Farb-Coding –
wird aus dem Prototyp ganz schnell ein echtes Werkzeug.
Eins, das nicht nur schön aussieht,
sondern produktiv ist.
Wie es weitergehen könnte
Ich sehe mehrere Pfade,
und keiner davon muss riesig sein.
Man könnte einfach klein weiterbauen:
Nodes speichern, Verbindungen halten, JSON exportieren,
vielleicht eine kleine Toolbar zum Erstellen neuer Workflows.
Oder man denkt größer:
Ein Online-Hub, in dem man Nodes hochlädt,
eine kleine Suchfunktion, ein Ratingsystem.
Keine zentrale Plattform, eher ein dezentrales Netzwerk,
das sich von selbst füllt, sobald genug Menschen mitmachen.
Das alles ist möglich,
weil FileMaker-Entwickler schon lange gewohnt sind,
ihre Lösungen anzupassen, zu teilen, weiterzugeben.
Das steckt in der DNA dieser Community.
Und vielleicht ist genau jetzt der richtige Zeitpunkt,
diese DNA in eine neue Form zu gießen.
Was das alles bedeuten könnte
Ich sehe das gar nicht als Konkurrenz zu n8n oder Make.
Die haben ihre Daseinsberechtigung,
ihre Cloud-Anbindung, ihre Integrationen.
Aber FileMaker hat etwas, das sie nicht haben:
Nähe.
Das System lebt lokal, arbeitet mit echten Daten,
in kontrollierten Umgebungen.
Wenn man darauf einen Node-Editor setzt,
bekommt man etwas, das beides kann:
die Offenheit moderner Workflows
und die Sicherheit eines bewährten Systems.
Ein FileMaker-basierter Node-Editor wäre kein weiteres Integrationstool,
sondern eine visuelle Erweiterung dessen,
was FileMaker ohnehin schon kann.
Er würde Entwicklern helfen,
ihre Logik zu verstehen, zu teilen und zu erweitern –
und Anfängern zeigen,
dass Low-Code auch schön aussehen darf.
Und jetzt?
Ich weiß noch nicht, wohin das alles führt.
Vielleicht bleibt es ein Experiment.
Vielleicht wird es zu einem kleinen Open-Source-Projekt.
Vielleicht wird es größer,
und die Community trägt es weiter.
Was ich aber sicher weiß:
Der FMVisualNodeEditor hat etwas ausgelöst.
Etwas, das viele FileMaker-Entwickler kennen,
aber selten laut sagen:
den Wunsch, die Dinge nicht nur zu bauen,
sondern auch zu sehen.
Und das, finde ich, ist ein ziemlich schöner Anfang.
Wenn du das hier liest und denkst,
„da würde ich gern mitmachen“,
dann tu’s.
Schau dir den Prototyp an.
Überleg dir, welche Script-Schritte du als Node sehen willst.
Oder fang einfach an, ein Mapping zu schreiben.
Mach’s nerdig, mach’s schön,
mach’s so, wie du FileMaker siehst.
Weil am Ende genau das zählt:
Dass FileMaker wieder ein bisschen mehr Spaß macht.
