Datenmodellierung
Karsten Risseeuw
ab FileMaker Pro 12
Modulare Konzepte
FileMaker Module und neue Ansätze
Todd Geist hat auf der Website modularfilemaker.org eine
schlichte Idee für FileMaker Module präsentiert, die immer
mehr Anhänger findet. Ausgehend von dieser Idee habe
ich eine schlanke Entwicklungsumgebung erarbeitet,
die sich weitgehend auf FileMaker Module stützt. Diese
beiden Ansätze können dazu beitragen, die FileMaker Ent-
wicklung für viele zu vereinfachen. Im vorliegenden Artikel
erläutere ich die dahinterstehenden Überlegungen und
Konzepte.
Einfacher ist besser. Wer mit FileMaker anfängt, tut das häu-
fig, weil der Einstieg besonders leicht ist und fast jeder sofort
ansehnliche Resultate erzielen kann. Das ist eine der großen
Stärken von FileMaker. Doch Programme entwickeln sich,
Anforderungen steigen und bevor man es merkt, wurde aus
einem einfachen Anfang eine komplexe Lösung. Schwerwie-
gender als die Komplexität ist jedoch die sich oft einstellende
Unübersichtlichkeit, die die Pflege und Weiterentwicklung
behindert oder auf Dauer gar unmöglich macht. Gibt es einen
Weg zurück in die Vereinfachung?
Es gibt verschiedene Ansätze zur Strukturierung und Harmo-
nisierung der Entwicklung, beispielsweise Programmierricht-
linien, man erstellt sich eine Startdatei oder entwickelt gar ein
umfassendes System – „Leitplanken“, die dabei helfen sollen,
nachvollziehbar und sicher ans Ziel zu gelangen. Im Glücks-
fall wird dabei gleichzeitig die Entwicklungsdauer reduziert.
In der Realität sieht es allerdings so aus, dass fast jeder Ent-
wickler seine eigenen „Leitplanken“ erstellt. Die FileMaker
Entwickler sind eine sehr heterogene Gruppe mit ganz unter-
schiedlichen Vorgehensweisen: Während einige sehr struktu-
riert arbeiten und die Konventionen millimetergenau imple-
mentieren, können andere damit überhaupt nichts anfangen.
FMM_201501  © 1994 – 2015  K&K Verlag GmbH, Hamburg
(Jg. 1961) Religionslehrer, Typograf, Fotograf,
Besitzer einer Bildagentur, Software­entwicklung
und Consulting für Bild­datenbanken, FileMaker
Entwickler.
karsten@kursiv.com
Nachdruck aus dem
FileMaker Magazin
siehe auch: www.filemaker-magazin.de
Das heißt nicht, dass die Programmierung in dem einen Fall
besser und im anderen schlechter ist, sondern nur, dass sich
der Weg zum Endresultat unterscheidet.
Dem Dogmatiker geht es um das Einhalten der Prinzipien
und Konventionen, da seiner Ansicht nach damit die bes-
ten Voraussetzungen für erfolgreiche Programmierung ge-
schaffen werden. Bei dem Pragmatiker hingegen steht das
Endresultat im Fokus – der Weg dorthin ist für ihn weniger
relevant. Beide stolpern irgendwann über die Grenzen des ei-
genen Ansatzes: Während der Dogmatiker Gefahr läuft, sich
in endlosen Konventionen zu verheddern, kann dem Pragma-
tiker aufgrund fehlender Strukturen schon mal die Übersicht
abhanden kommen. Wahrscheinlich war es dieser Zusam-
menhang, in dem die Ideen zur Modularität aufkamen, denn
Module können die Programmierung sowohl vereinfachen als
auch strukturieren.
Modularität
Modularität ist der Ansatz, eine Struktur aus Teilbereichen,
Komponenten und Bausteinen zu gestalten. Module sind
Funktionen oder Aufgabenbereiche, die mehr oder weniger
abgekapselt sind und über Schnittstellen mit den übrigen
Programmteilen kommunizieren. Modularität bietet für
den Dogmatiker wie für den Pragmatiker Vorteile, denn sie
verringert einerseits die Komplexität, weil sie mit kleineren
Komponenten arbeitet, und stellt andererseits eine sinnvolle
Struktur zur Verfügung.
Natürlich ist auch die Modularität ein weit gefächerter Be-
reich und so gibt es ganz unterschiedliche Ansätze und Ar-
ten der Umsetzung. Während der Dogmatiker höchstwahr-
7

Datenmodellierung
scheinlich eine exakte Definition bevorzugen wird, zelebriert
der Pragmatiker den schnellsten Weg zur Umsetzung. Es er-
scheint deshalb angebracht, noch einmal grundsätzlich über
die Art der gewünschten Modularität nachzudenken – vor al-
lem, wenn sie sich im Hinblick auf eine möglichst große Zahl
von Anwendern bewähren soll. Auf dieses Thema kommen
wir später genauer zu sprechen.
Bei dem Begriff „Modul“ denken viele an konkrete Lösun-
gen, wie z. B. ein Adress- oder ein Rezeptmodul. Das ist na-
türlich eine mögliche Anwendung der Grundidee, aber es gibt
auch andere Herangehensweisen. Todd Geist beispielswei-
se hat in viel kleineren Einheiten gedacht. Nach seiner Idee
sind FileMaker Module möglichst kompakte und fokussierte
Funktionen, wie beispielsweise eine Suchfunktion, eine vir-
tuelle Liste oder Ähnliches, die eine einzige, klar definierte
Aufgabe lösen und sich an ganz verschiedenen Stellen im Pro-
gramm nutzen lassen.
2012 lancierte Todd Geist die Website modularfilemaker.org,
wo er die Idee von FileMaker Modulen präsentiert: kleine,
funktionelle Einheiten für die tägliche Programmierarbeit,
die sich – das ist seine zentrale Anforderung – einfach aus-
tauschen lassen. Anders als bei den meisten Entwicklungs-
plattformen schreibt man in FileMaker keinen Code, alle
Funktionalität ist in Dateien eingebunden. Zwar lassen sich
beispielsweise Scripts oder Tabellen importieren, Layouts
aber nicht. Der Austausch programmierter Funktionalitäten
wird von FileMaker nicht unterstützt. Hier kommt die Idee
von FileMaker Modulen ins Spiel: Mit einer simplen Struktur
werden Teile der Programmierarbeit aus- und in einem neuen
Projekt wieder eingegliedert. Damit kommen wir dem Traum
vom wiederverwendbaren Code einen Schritt näher.
Als Vehikel für den Austausch dienen Modul-Dateien.
FileMaker Dateien enthalten alles, was FileMaker zu bie-
ten hat, weshalb Dateien die einzige umfassende Lösung für
den Datenaustausch sind. Modul-Dateien transportieren die
Funktionalität. Möchte man ein Modul in die eigene Lösung
integrieren, dann bietet das Modul eine Schritt-für-Schritt-
Anleitung, wie die Tabellen, Scripts und Layouts in die eigene
Datei übernommen werden können.
Diese FileMaker Module kennen keine Programmierricht­
linien und keine komplexen Konventionen, sondern stellen
eine Ablagestruktur dar, die beispielsweise Ordner für die Ab-
lage von Scripts oder Layouts betrifft. Im Klartext: Jeder kann
programmieren wie er will, wenn er nur die Ablagestruktur
einhält.
Eine weitere wichtige Eigenschaft von FileMaker Modulen
bezieht sich auf die Trennung von Funktionalität und Para-
metrisierung. Damit Scripts einfach an neue Projekte ange-
passt werden und auch andere Programmierer mit den Mo-
dulen arbeiten können, werden die ausführenden Scripts von
den Einstellungsscripts getrennt. Aus diesem Grund lagere
ich spezielle Tabellenverweise, Textlabels oder andere spezifi-
sche Parameter in einem Einstellungsscript aus.
8
Nachdruck aus dem
FileMaker Magazin
siehe auch: www.filemaker-magazin.de
Beim Aufruf des Hauptscripts kann beispielsweise das Ein-
stellungsscript eingelesen werden. Das hat gleich zwei Vortei-
le: Erstens sind alle Einstellungen oder änderbare Parameter
an einem einzigen Ort abgelegt und zweitens wird die An-
passung von Modulen an neue Projekte ganz entscheidend
vereinfacht. Wenn ich ein Modul benutze, das jemand anders
erstellt hat, muss ich mich nicht mit dem anderen Program-
mierstil herumschlagen, sondern lediglich die Parameter aus
dem Einstellungsscript richtig konfigurieren, sodass das Mo-
dul für meine Situation angepasst wird.
Aufbau von FileMaker Modulen
Eine wichtige Voraussetzung ist, dass ein Modul in sich funk-
tioniert – mit allen Tabellen, Feldern, Scripts und Layouts so-
wie weiteren Einstellungen, die alle spezifisch zu diesem einen
Modul gehören. Die Ablagestruktur sieht aus diesem Grund
für jedes Modul einen eigenen Ordner vor. So gibt es beispiels-
weise im Script-Fenster einen Ordner „Module“, in dem sich
für jedes Modul ein Ordner mit dem Modulnamen befindet.
Dieselbe Struktur lässt sich auch für Layouts nutzen. Dass
eine Datei durch diese Herangehensweise mehr Tabellen und
Layouts enthält als es sonst der Fall wäre, hat keinen Einfluss
auf die Performance, erhöht die Übersichtlichkeit aber enorm.
Wer anfängt, nach diesen einfachen Vorgaben zu strukturie-
ren, merkt rasch, dass Querverweise von Scripts auf zentrale
andere Tabellen oder Layouts dem Konzept widersprechen
– so wird einer Programmierung, bei der alles mit allem ver-
knüpft ist (Spaghetti-Programmierung), entschieden entge-
gengewirkt. Bestehen Abhängigkeiten zu anderen Modulen,
müssen diese in einem „ReadMe-Script“ sauber deklariert
werden. Auch dieses Script ist fester Bestandteil der Ablage-
struktur, sodass jeder weiß, wo er nach Angaben zur Integra-
tion suchen muss.
Im Script-Ordner lässt sich am deutlichsten erkennen, dass FileMaker Module eine
klare und einfache Struktur haben.
FMM_201501
 Nachdruck aus dem
FileMaker Magazin
siehe auch: www.filemaker-magazin.de
Es gibt übrigens keine Vorgabe, dass ein Modul zwingend Ta-
bellen, Layouts oder Scripts verwenden muss. Ich habe einige
Module erstellt, die lediglich aus Scripts bestehen und nur op-
tional mit Tabellen oder Feldern zusammenarbeiten. Weitere
Angaben zu FileMaker Modulen sind direkt auf der Website
modularfilemaker.org zu finden. In diesem Artikel möch-
te ich den Fokus eher auf die Konzepte als auf die technische
Umsetzung legen.
Programmierrichtlinien oder
Strukturen?
Wohin führen diese Erfahrungen? Und wie geht es weiter?
Seit etwa einem halben Jahr stelle ich einige Module auf mei-
ner Website kostenlos zur Verfügung. Rückmeldungen von
Anwendern zeigen, dass es gerade die einfache Struktur dieser
FileMaker Module ist, die eine rasche Akzeptanz, Integration
und Umsetzung möglich macht. Man muss sich nicht in Kon-
ventionen eindenken, sondern kann direkt anfangen, mit den
Modulen zu arbeiten.
Selbst Anfänger können ein Modul, das sie z. B. von modu-
larfilemaker.org heruntergeladen haben, meist mit wenigen
Schritten erfolgreich in die eigene Lösung integrieren. Der
Einstieg ist super leicht, auch weil die Integrationshilfe Teil
der Script-Struktur ist. Außerdem spielt es kaum eine Rol-
le, nach welchen Programmierrichtlinien ein Modul erstellt
wurde. Entscheidend ist, ob es sich einfach einbinden, para-
metrisieren und nutzen lässt. Genau das erlaubt die Idee der
FileMaker Module.
„Man soll es so einfach wie möglich machen, aber nicht ein-
facher.“ Dieser Spruch, der Einstein zugeschrieben wird, lässt
sich auch auf die Modularität anwenden – es geht um eine
Gratwanderung zwischen Definition und Freiheit, zwischen
Programmierrichtlinien und schlichten Strukturen. In den
letzten zwei Jahren habe ich festgestellt, dass eine schlichte
Struktur und Zugänglichkeit vielleicht mehr zum Erfolg einer
Idee beitragen als eine mehr oder weniger rigide Konvention,
egal wie gut durchdacht sie ist.
Das liegt vermutlich daran, dass der größte Knackpunkt bei
der Programmierung die Vereinfachung ist – Komplexität
entsteht von selbst, die Vereinfachung ist die Kunst. Sollten
künftig weitere Konzepte zur modularen Programmierung
mit FileMaker entstehen, erwarte ich, dass die Faktoren
„Schlichtheit“ und „Zugänglichkeit“ über die Akzeptanz ent-
scheiden, wie das übrigens bei allen Gebrauchsgegenständen
der Fall ist.
An der Idee von Todd Geist sehe ich zwei Dinge als wegweisend:
1) Die Struktur ist wichtiger als jede Konvention
2) Funktionalität und Parametrisierung werden getrennt
Punkt 1 erlaubt es jedem Entwickler, mit seinem aktuellen
Wissensstand einzusteigen und sich auf den Weg zu machen,
einfacher und modularer zu programmieren. Dabei kann er
FMM_201501 
Datenmodellierung
sich selbst stetig verbessern und neue Versionen seiner Module
veröffentlichen – alles innerhalb derselben Struktur. Punkt 2
erleichtert die Integration und die Modulpflege. Beide Punk-
te zusammen definieren jedoch noch lange nicht, bis zu wel-
chem Grad tatsächlich modular programmiert wird.
Es gibt auch keine Vorgaben zum Programmierstil oder dazu,
wie sich Module am besten integrieren lassen. Hier sind noch
viele Fragen offen, und es wird sich zeigen, was sich am besten
bewährt. Das Gute ist, dass jeder an der Beantwortung dieser
Fragen mitarbeiten und seinen Beitrag leisten kann. Außer-
dem regt das Fehlen von ausformulierten Konventionen den
Austausch und die Kreativität an. So entstehen im Laufe der
Zeit die „Best Practices“.
Ich kann mir vorstellen, dass diese Formulierungen für einige
zu vage sind und sie sich fragen, ob ein System bzw. eine Kon-
vention nicht viel effizienter wäre. Gibt es nicht bereits viele
bewährte Methoden? Das stimmt. Ein Regelwerk aufzustel-
len ist aber nur eine Methode, etwas in die Hand zu nehmen,
weshalb ich im Folgenden zwei Herangehensweisen nebenei-
nander gestellt habe:
A. Das System
Es wird ein Regelwerk definiert, wie programmiert werden
soll. Dazu gibt es vielleicht eine oder mehrere Starterdateien,
Konventionen für die Benennung von Dateien, Scripts, Lay-
outs, Feldnamen usw., sodass ein fantastisches System ent-
steht, das von A bis Z durchdacht ist … Natürlich kann nur
das berücksichtigt werden, was den Entwicklern des Systems
bis dato in den Sinn gekommen ist und was gerade aktuell in
und mit FileMaker möglich ist. Weil besonders viel definiert
ist, wird es an diesem System besonders viel zu ändern geben.
Da es sich aber um ein Regelwerk handelt, stolpert das System
über die eigenen Regeln, wenn die Programmentwicklung in
eine Richtung geht, für die noch keine Regeln bestehen, oder
neue FileMaker Versionen und Funktionalitäten alte Regeln
überflüssig machen. Dies erfordert regelmäßige Aktualisie-
rungen.
Stellen Sie sich vor, Sie haben ein Projekt angefangen, bei
dem Sie System 1.0 eingesetzt haben. Ein halbes Jahr später
arbeiten Sie an einem weiterem Projekt, mit der mittlerweile
aktuellen Version 1.32. Es folgen weitere Projekte und weite-
re Systemversionen. Wer das warten und supporten muss, ist
bei jedem Projekt an das Regelwerk der einzelnen Systemver­
sionen gebunden und muss entweder alle Systeme auf densel-
ben Stand bringen oder mit unterschiedlichsten Regelwerken
zurechtkommen. Die Konsistenz wird also nur mit hohem
Aufwand erreicht. Wer soll das bezahlen?
B. Die modulare Struktur
Hier steht nicht das System im Vordergrund, sondern die
Struktur. Nicht alles ist definiert, aber alles hat einen (un-
gefähren) Platz. Die Entflechtung der Funktionen, Scripts,
Tabellen und dergleichen ist weit fortgeschritten: Es gibt Mo-
9

Datenmodellierung
dule für verschiedenste Funktionen, auf die immer wieder zu-
rückgegriffen werden kann.
Fehlt eine Funktion, kann problemlos ein Modul eines ande-
ren Entwicklers integriert werden, auch wenn der Program-
mierstil ein anderer ist. Sollte ein größeres Projekt entstehen,
können verschiedene Entwickler mit der Erstellung einzelner
Module beauftragt werden, die sich später zu einem Gesamt-
system zusammenschließen lassen. Die einzige Vorgabe wäre,
dass die Module sich einfach in die modulare Struktur ein-
betten lassen. Wenn mit der Zeit verschiedene Projekte reali-
siert werden, entstehen zwar auch hier Differenzen zwischen
den Versionen, aber es ist keine Aktualisierung verschiede-
ner Konventionen nötig, sondern lediglich der Abgleich von
Modulfunktionalitäten. Bei Bedarf können sogar Module
ausgetauscht werden, ohne dass ein „System“ dadurch infrage
gestellt wird.
FM Starter nutzt und erweitert die Struktur im Script-Fenster, Ordner für
­Module und Fenster sind vorgegeben. Weitere Entwicklungen landen vermutlich
im Ordner „Application specific“ („spezifisch für die Anwendung“).
Auch wenn es realistisch erscheint, eine offene Struktur durch
diverse Konventionen zu ergänzen, sind es nicht die Konventi-
onen, die im Vordergrund stehen, sondern der Fokus liegt auf
der offenen, leichten Struktur. Weil viel mit Bausteinen gear-
beitet wird, bleibt diese Struktur flexibel, denn die Bausteine
sind weitgehend unabhängige Komponenten.
10
Nachdruck aus dem
FileMaker Magazin
siehe auch: www.filemaker-magazin.de
Dass sich mit beiden Varianten gute Lösungen erstellen las-
sen, soll keineswegs angezweifelt werden. Doch der Ausgangs-
punkt dieses Artikels war die Frage, ob es einen Weg zurück
in die Vereinfachung gibt. Nehme ich diese Frage als Leit­
faden, kann ich in größeren Systemen keine Vereinfachung
erkennen, bei modularen Ansätzen sehe ich jedoch ein großes
Potenzial dafür.
Auch bei den Layouts wird dieselbe Struktur wie im Script-Fenster beibehalten
Module und modulare Systeme
Todd Geist spricht von FileMaker Modulen und meint damit
unabhängige, auf bestimmte Funktionen getrimmte Kompo-
nenten. Spinnt man den Gedanken etwas weiter, könnte ein
Modul nicht nur eine Funktion, sondern auch einen Lösungs-
bereich beinhalten, etwa eine funktionierende Datenbank
mit einer bestimmten Aufgabe (Adressmodul, Verkaufsmo-
dul, Bilddatenbank usw.). Auch Module dieser zweiten Grup-
pe könnten unabhängig, also ohne Verweise auf andere Teile
funktionieren.
Etwas anderes ist es jedoch, wenn man von „modularen Syste-
men“ spricht. Diese können zwar ebenfalls Module einsetzen,
definieren aber nicht nur die allgemeine Struktur, sondern
auch die Schnittstellen. Insofern stellt ein modulares System
eine Hybrid-Version eines Systems und eines modularen An-
satzes dar. Selbstredend hat man hier sowohl die Vor- als auch
die Nachteile beider Herangehensweisen.
Jeder dieser Ansätze hat seine Berechtigung, doch man könn-
te sich überlegen, welche Art der Modularität (ohne die an-
dere Varianten auszuschließen) die interessanteste Weiterent-
wicklung verspricht. Ich selbst habe mich – in Anlehnung an
die Ideen von Todd Geist – für folgende Betrachtungsweise
entschieden: Die Struktur ist wichtiger als ein Regelwerk,
FMM_201501
 Nachdruck aus dem
FileMaker Magazin
siehe auch: www.filemaker-magazin.de
weil sie mir größere Flexibilität und vermutlich auf Dauer eine
größere Vereinfachung erlaubt. Außerdem sind freistehende
Module für mich interessanter als Systeme, weil mit ihnen
Abhängigkeiten vermieden werden. Ich möchte dadurch pro-
jekt- und „System“-unabhängige Programmierung fördern.
Würde ich nach einem Stichwort zur Definition dieser Rich-
tung gefragt, wäre das nicht „Modularität“, sondern vielmehr
„Entflechtung“.
Die Entflechtung
Ausgehend von Todd Geists Konzept der FileMaker Baustei-
ne habe ich nach einem Ansatz gesucht, der über diese kom-
pakten Module hinausgeht. Todd Geist selbst macht dazu
keinerlei Aussage und bietet weder Vorgaben noch Empfeh-
lungen an. Das ist auch richtig so, denn wie es weitergeht, ist
nicht das Thema von modularfilemaker.org. Er legt die Ver-
antwortung in die Hände der Entwickler – zweifellos auch,
damit weitere innovative Ideen gefunden werden. Auf seiner
Firmenwebsite geistinteractive.com gibt es ein Video mit
dem Titel „Modular FileMaker Application Development“,
das einen sehr interessanten Einblick in die Arbeitsweise von
Todd Geist bietet. Er beschreibt darin, wie er selbst bei neuen
Projekten zu neuen Modulen kommt und wie er diese schritt-
weise entwickelt, zeigt aber keinen Lösungsansatz für kom-
plette Projekte. Wer sich auf dieser Website umschaut, findet
in dem Blog-Beitrag „What can WordPress teach FileMaker?“
ein Plädoyer für modulare Ansätze und einen Vergleich zwi-
schen FileMaker und WordPress in dieser Hinsicht.
Wie soll es also weitergehen? Zwei Stichwörter hatte ich be-
reits gefunden: Portabilität und Entflechtung. Die Portabili-
tät, die zuerst einmal die FileMaker Module betrifft, soll da-
bei helfen, besser und vielseitiger zusammenzuarbeiten. Die
Entflechtung dagegen ist etwas, was bei den Modulen sichtbar
wird, sich aber auch für die gesamte Entwicklung überneh-
men lässt. Hierbei geht es vor allem um die Entflechtung von
Abhängigkeiten zugunsten einer besseren Übersichtlichkeit,
z. B. bei Aufgabenbereichen innerhalb einer Applikation, von
Scripts und Layouts, Tabellen und Funktionen.
Diese Gedanken haben mich zu einem Lösungsansatz ge-
führt, den ich auf der diesjährigen FileMaker Konferenz in
Winterthur vorgestellt habe – zunächst im Rahmen eines
Vortrages zu FileMaker Modulen, dann aber auch als Pro-
dukt, das ich auf der Konferenz lanciert habe und das bereits
in den ersten Wochen von etwa einem Dutzend FileMaker
Entwicklern übernommen wurde. Zudem fanden bereits ver-
schiedene Workshops und Schulungen statt.
Das Produkt: „FM Starter“
Das Produkt heißt FM Starter und ist eine Starterdatei, die
die bisherigen Gedanken zusammenfasst. Es ist keine Vorgabe
oder Konvention, sondern vor allem eine offene Struktur. Je-
der kann programmieren wie er will und gleichzeitig auf An-
hieb die Struktur und die vorhandenen Module nutzen. Die
Struktur lehnt stark an die Ideen eines modularen FileMaker
FMM_201501 
Datenmodellierung
an und es wurden bereits viele Elemente als FileMaker Module
eingebunden. FM Starter will Hilfe zur Selbsthilfe anbieten,
wobei die Datei vermutlich nichts perfekt macht, aber trotz-
dem eine ganze Reihe von Anforderungen löst. FM Starter ist
ein Anfangspunkt für neue Projekte und zeigt eine Richtung
für die weitere Entwicklung an.
Obwohl die Idee zu diesem Projekt primär meinen eigenen
Bedürfnissen entsprang, habe ich doch auch im Austausch
mit anderen Entwicklern regelmäßig gehört, dass sowohl eine
Art Modularität wie auch eine eigene Starterdatei sehr hilf-
reich wären. Ein weiterer Punkt, der mich angetrieben hat,
war meine eigene Anfangszeit mit FileMaker: Viele Themen
musste ich mir mühsam erarbeiten und die Suche nach guten
Lösungen hat Jahre beansprucht. Wie froh wäre ich um eine
solche integrierte Starterlösung gewesen, die mir enorm viel
Entwicklungszeit gespart hätte. Auch mein Lernprozess wäre
um einiges schneller gewesen, denn nichts ist so hilfreich wie
der Einblick in die Arbeit eines anderen Entwicklers.
Die Ideen hinter „FM Starter“
n Gut integrierte Basismodule: dynamische Navigation,
Benutzerverwaltung, mehrsprachige Textlabels, Such-
funktionen usw.
n Einfache Ordnerstruktur für Scripts, Layouts usw.
n Einfache Fensterstruktur
n Alle Angaben für Benutzer, Administratoren und Ent-
wickler (!) übersichtlich und in eigenen Fenstern direkt
zugänglich
n Alle Einstellungen über reguläre Layouts anpassbar
n Grafikbibliothek
n Ansprechende Themen
n Toolbox-Fenster für schnellen Zugriff auf Textlabels
und Grafiken
n Alles in Scripts und Layouts gut dokumentiert
n Einstellungen für die Software (Name, Version, Lizenz,
Über … usw.)
n Deutsches Online-Handbuch (englisches Handbuch
in Vorbereitung)
Das zentrale Element der Lösung stellt die Navigation dar.
Sie ist dynamisch, mehrsprachig, mit der Benutzerverwal-
tung verknüpft und kann Parameter für die Zielseite mitge-
ben. Außerdem können mehrere Fenster aus derselben Navi­
gationstabelle gespeist werden, sodass jedes Fenster seine
eigene Navigationsstruktur hat. Die Navigation bietet also auf
Anhieb eine effiziente Strukturierungsmöglichkeit. Layouts
und Scripts können Modulen, Fenstern oder Seiten zugeord-
net werden. Alle diese Varianten stehen bei den Layouts und
Scripts in einer ebenso organisierten Ordnerstruktur.
Eine weitere Strukturierungshilfe betrifft die Fenster, wo es
aufgabenspezifische Unterteilungen gibt. Das Standardpro-
gramm läuft in einem einzigen Hauptfenster, das für den re-
11

Datenmodellierung
gulären Benutzer gedacht ist. Bei den meisten Applikationen
gibt es jedoch auch administrative Aufgaben, wie beispiels-
weise die Verwaltung von Benutzer-Accounts oder bestimm-
te Software-Einstellungen. Diese Funktionen werden nicht
so häufig gebraucht und sollten nur den Administratoren
zugänglich sein. Was ist einfacher, als sie in ein eigenes Auf­
gabenfenster zu verlegen? Das war die Geburt des Adminis-
tratorfensters. Auch hier greift das Navigationsmodul und
bietet eine eigene Struktur, wodurch beliebig viele Einstel-
lungslayouts schnell und übersichtlich eingebunden werden
können.
Neben dem Administrator hat auch der Entwickler ein eige-
nes Fenster. Das erhöht nicht nur den Komfort, sondern er-
mutigt ihn auch dazu, eigene Erweiterungen und Hinweise in
derselben Struktur abzulegen: Module, Einstellungen, Tipps
& Tricks und vieles mehr. Die Fensterstruktur ist keine Pro-
grammierrichtlinie, sondern eine schlichte Strukturierungs-
hilfe, die man nutzen oder abändern kann. Sie entspricht
einer Struktur, die ohnehin von den meisten Entwicklern
benutzt wird.
Die Entflechtung der Programmierarbeit lässt sich auch im
Script-Bereich realisieren. Hierfür wurden in FM Starter
zwei Ansätze verfolgt:
Lokal Sofern Scripts nicht zu Modulen oder bestimmten
Aufgaben gehören, lassen sie sich häufig auf einzelne Lay-
outs begrenzen. In FM Starter werden viele Layout-Scripts
genutzt, die nur Funktionen für die jeweiligen Layouts verar-
beiten. Werden Funktionen aus anderen Scripts oder von an-
deren Tabellen benötigt, wird auf die entsprechenden Layouts
und Layout-Scripts verwiesen. Der Vorteil dieser Arbeitswei-
se ist die Entflechtung von Scripts, die sonst in viele Layouts
oder Tabellen hineinwirken. Außerdem werden Doppelspu-
rigkeiten vermieden und es wird eine generische Arbeitsweise
gefördert. Wenn beispielsweise eine neue Adresse angelegt
werden soll, dann nur im Layout-Script für das Layout „Ad-
ressen“.
Die zentrale Navigation in FM Starter baut auf einer Tabelle auf, deren Parameter in jedem Layout dynamisch abgerufen werden.
12
Nachdruck aus dem
FileMaker Magazin
siehe auch: www.filemaker-magazin.de
Verdichtung  Scripts werden multifunktional aufgesetzt, das
heißt, ein einzelnes Script kann mehrere Aufgaben erfüllen.
Damit das möglich ist, stehen alle Script-Anweisungen grund-
sätzlich in „Wenn“-Abfragen. Der Aufruf des Scripts erfolgt
mit einem Scriptparameter, der von den „Wenn“-Abfragen
mit „Hole (ScriptParameter)“ evaluiert wird. So kann ein ein-
ziges Layout-Script problemlos zehn verschiedene Aufgaben
erfüllen. Eine Deklaration der Scriptparameter zu Anfang
des Scripts erhöht die Übersichtlichkeit; wird kein Parameter
übergeben, macht das Script nichts. Diese Vorgehensweise ist
ebenfalls nur eine Idee für eine Struktur und keine Program-
mierrichtlinie. Die Anzahl der Scripts nimmt drastisch ab
und es ist auf Anhieb klar, wo ein Script zugeordnet ist (z. B.
Modul-Script, Layout-Script). Das vereinfacht die Programm-
pflege erheblich.
FM Starter kann nicht alles und muss auch nicht alles kön-
nen. Das Programm ist offen für Erweiterungen und will dem
Entwickler einen einfacheren Start bieten. Weitere Module
lassen sich nicht nur bequem einbinden, sondern auch pro-
blemlos in die vorhandene Struktur einordnen. Die weitge-
hende Entflechtung hilft dabei, aus FM Starter auf einfache
Weise eine eigene Starterlösung zu kreieren.
Wer es besser kann oder anders machen würde, ist eingeladen,
einen entsprechenden Beitrag zu verfassen. Gewiss entstehen
gerade dadurch die besten Ideen für eine zukunftssichere und
modulare FileMaker Entwicklung. Auf Basis von FM Starter
gibt es bereits einen regen Austausch und neue Ideen finden
den Weg in den Alltag. Das ist meines Erachtens die beste Vo-
raussetzung für weitere Entwicklungen. ♦
Literaturangaben, Websites
modularfilemaker.org – FileMaker Module, Konzepte
kursiv-software.com – FM Starter, FileMaker Module
kursiv.ch – Workshops
fmstarter.com – demnächst: die zentrale Seite zu FM Starter mit
Support, Knowledge Base usw.
FMM_201501
 2008 01

Das unabhängige Magazin für FileMaker Anwender und Entwickler FMM_200801

Deutschland e 9,50 | www.filemaker-magazin.de

Geschüttelt, nicht gerührt …

Das FileMaker Magazin

Gut zu wissen

Ist Maintenance ● Einzige, deutschsprachige Fachzeitschrift zu FileMaker

eigentlich ansteckend?
FileMaker für Einsteiger ● Wissen aus erster Hand von anerkannten FileMaker Fachautoren
Wie Sie in FileMaker Ihre
ersten „Felder bestellen“ ● Große Themenvielfalt für Anwender, Entwickler und
Fortgeschrittene
Buchbesprechungen

Neue Fachbücher
zu FileMaker 9
© 1994 - 2008 K&K Verlag GmbH, Hamburg

Exklusiv für Premium-Abonnenten

FMM_2008_01.Titel.indd 1 29.04.2008 10:09:42 Uhr

● Sechs FMM Ausgaben pro Jahr

● Kostenlose Nutzung des Abonnentenbereichs auf
www.filemaker-magazin.de
● PDF-Online-Archiv mit allen bisher erschienenen Ausgaben
● Jede Ausgabe mit kostenlosen Beispieldateien und Zusatzinfos
zum Download

Unser Service
● Aktuelle Neuheiten, Tipps und Infos, Kleinanzeigen und
vieles mehr jederzeit online auf unseren Webseiten
● Hilfe bei allen Fragen zu FileMaker im FMM Forum
● Kompetente Beratung zum Kauf von FileMaker Lizenzen:
Einfach anrufen +49 (0)40 589 65 79 70.

Hier finden Sie Aktuelles zu FileMaker

Produkten, egal ob Sie kaufen, mieten
oder sich einfach informieren möchten.

Wenn Sie sich für ein

Eine kostenlose Leseprobe des FileMaker Magazin Abo
FileMaker Magazins erhalten Sie, interessieren, klicken Sie
wenn Sie hier klicken. bitte hier!

K&K Verlag GmbH · www.filemaker-magazin.de · Telefon +49 40 589657970