Grössere Projekte als Add-on speichern

Erfahrungsbericht

Grössere Projekte als Add-on speichern

Getestet mit FM Starter 2


28. Mai 2021In Erfahrungsbericht, TippsBy Karsten Risseeuw8 Minutes

FileMaker Add-ons werden oft als kleine Lösungen angepriesen. Wie ist es jedoch, wenn man grössere Projekte, mit vielen Tabellen, Scripts, Layouts, usw. als Add-on exportiert. Geht das?

Die Herausforderung

Alle mir heute bekannte Add-ons für FileMaker sind «kleine» Projekte. Es sind Funktionen, einfache Lösungen mit relativ wenig Tabellen, Layouts und Scripts. Kann man grössere Add-ons generieren und warum sollte man das wollen?

Die Frage, ob man grössere Add-ons generieren kann, habe ich getestet. Dazu gleich mehr. Aber warum sollte man das wollen? Ist es nicht genug, dass man kleine, spezifische Projekte lancieren kann? Nun, Add-ons sind praktisch und manche Aufgaben sind etwas komplexer, benötigen also komplexe oder grössere Add-ons.

Man kann beispielsweise eine einfache aber komplette Adressverwaltung als Add-on erstellen. Das könnte ein Basis-Modul zur weiteren Entwicklung sein, mit allen wichtigen Tabellen bereits verlinkt und einige Funktionen eingebaut. Ebenso liesse sich ein Rechnungsmodul als Add-on entwickeln, mit den Basistabellen für Belege, Rechnungspositionen, Drucklayouts, usw. Es geht um die Frage, wie gross oder komplex die Bausteine sein dürfen.

Gelingt es, grössere Bausteine zu erstellen, dann gelingen auch andere Projekte schneller.

FM Starter als Add-on

FM Starter ist die Startdatei, die wir als Produkt verkaufen. Mit ihr lässt sich jedes neue FileMaker-Projekt besonders schnell einrichten und wichtige Funktionen sind bereits integriert. Es ist eine grosse Starthilfe für alle «neuen» Projekte. So vermarkten wir das auch.

Regelmässig habe ich jedoch Entwickler am Telefon, die bereits ein Projekt am Laufen haben, und gerne die Funktionalität von FM Starter integrieren würden. «Kann man FM Starter auch in ein bestehendes Projekt integrieren?» ist eine Frage, die ich regelmässig höre. Meine Antwort darauf ist stets: Ja, das geht, aber…

FM Starter ist fast komplett modular aufgebaut. Dadurch kann man FM Starter Modul für Modul in eine andere Datei übernehmen. Es geht, auch wenn es aufwändig ist. Relationen gibt es keine (ausser 1 Relation für die Design-Seite, wodurch Portale dargestellt werden können). Die Voraussetzungen sind also gut. Die Datei hat trotzdem recht viele Tabellen, unzählige Scripts, Einstellungen und viele Dinge mehr. Erschwerend ist, dass viele Module sich gegenseitig nutzen. Beispielsweise nutzt das Modul «Navigation» die Module «Benutzerverwaltung» und «Mehrsprachigkeit».

Möchte man die Originaldatei von FM Starter in ein anderes Projekt integrieren, dann ist das sehr aufwändig. Kann man die gesamte Startdatei als Add-on speichern, dann ebnet das den Weg zur Integration in andere Projekte. Es wäre viel einfacher, die Datei mit dem FM Starter Add-on auszustatten.

Einschränkungen bei Add-ons

FileMaker Add-ons übernehmen Tabellen, Layouts, Objekte, Scripts und Custom Functions. Nicht jedoch werden Sicherheitseinstellungen und Konten übernommen. Diese beiden Dinge sind jedoch integrierter Bestandteil von FM Starter. Was passiert, wenn man diese Einstellungen verliert?

Der Test

Bevor man aus einer geschützten Datei wie FM Starter ein Add-on machen kann, muss man die Datei mit vollen Zugriffsrechten öffnen. Danach habe ich die Datei mithilfe von Add-On Lab FREE ausgewählt und als Add-on Paket gespeichert. Was geschah?

Erstaunlicherweise hat es geklappt. Es braucht aber Zeit. Beim Sichern der Datei als Add-on war FileMaker minutenlang eingefroren. Ich sah jedoch auf der Festplatte, dass Daten geschrieben wurden. Als das Add-on gespeichert war, habe ich eine neue, leere Datei geöffnet und dort das Add-on geladen.

Auch das Laden des Add-ons braucht seine Zeit. Danach stand FM Starter jedoch in einer neuen Datei zur Verfügung. Ich war erstaunt, dass es beim ersten Anlauf funktioniert hat. Nun aber musste ich das Resultat testen.

Bei diesem Test hatte ich keine «Drag-and-drop» Dateien erstellt. Es gab also nichts, was ich auf die Seite ziehen könnte. Das spielt jedoch keine Rolle, da beim Import des Add-ons bereits die ganze Funktionalität importiert ist. Das sieht man beispielsweise an die Liste mit Layouts.

Es wurden insgesamt 25 Tabellen mit ihren Datensätzen angelegt.

Die Konten und Sicherheitseinstellungen wurden – wie erwartet – nicht übernommen.

Bei den Scripts dagegen wurde die ganze Liste sauber übernommen.

Was funktioniert nicht?

In einem ersten Vergleich der Originaldatei mit dem Add-on sind ein paar Dinge aufgefallen:

  • Dateieinstellungen werden nicht übernommen.
    • Das StartUp-Script ([OnFirstWindowOpen]) wurde nicht zugeordnet.
    • Das CloseDown-Script ([OnLastWindowClose]) wurde ebenfalls nicht zugeordnet.
    • Diese und weitere Einstellungen lassen sich schnell beheben, sofern in einer bestehenden Lösung nicht bereits ähnliche Triggers konfiguriert waren. Ansonsten muss man diese Aufgabe lösen.
  • Die Navigation hat nicht auf Anhieb funktioniert
    • Dies hat zuerst mit dem StartUp-Script zu tun, dann aber auch mit fehlenden Konten, die beim Start ausgeführt werden
    • Diese und weitere Einstellungen können jedoch leicht angepasst werden.
  • Einige Layouts waren nicht sauber aufgebaut. Es gab einen Fall, wo der Button-Bar nicht sauber dargestellt war. Der Stil musste neu zugeordnet werden und das Objekt musste korrekt platziert werden.
  • Textobjekte erhalten pauschal die Textformat-Einstellungen der ersten Zeile. Eine differenzierte Hervorhebung «im» Text geht verloren und muss neu zugeordnet werden.

Alles in allem hat erstaunlich viel auf Anhieb funktioniert. Einige Anpassungen, die gemacht werden mussten, waren zu erwarten.

Können komplexere Add-ons erstellt werden?

Im Moment kommt man nicht ums Experimentieren herum. Die «FM Starter 2»-Datei wurde ohne Anpassungen zu einem Add-on umgewandelt. Dass dies weitgehend gelang, werte ich sehr positiv. Möchte man jedoch ein zuverlässiges Add-on erstellen, wäre es sinnvoll, die ursprüngliche Datei für diese Anwendung zu optimieren. Ausserdem benötigt es eine Dokumentation dazu, welche Anpassungen vom Entwickler noch gemacht werden müssen. Diese Anpassungen sind nicht nötig, wenn man die Startdatei direkt als Ausgangslage benötigt. Fehlen bei einem Add-on jedoch die FileMaker Konten und Zugriffsberechtigungen, kann das Add-on nicht so funktionieren wie in der Originaldatei.

Spezielle Aufmerksamkeit gilt demnach:

  • Dateieinstellungen
  • Konten und Zugriffsrechte.

Dieser kleine Erfahrungsbericht will aufzeigen, dass die Arbeit mit Add-ons keine Hexerei ist. Die guten Anwendungen entstehen erst und ich bin gespannt auf weitere Entwicklungen.

FM Starter 2

FileMaker Scripts für verschiedene Aufgaben gleichzeitig nutzen

FileMaker Scripts für verschiedene Aufgaben gleichzeitig nutzen

So erreichst Du mehr mit Deinen FileMaker Scripts


7. April 2021In TippsBy Karsten Risseeuw7 Minutes

FileMaker Scripts dienen dazu, Abläufe zu standardisieren. Es ist die «Programmiersprache» von FileMaker, wenn man so will. Meist werden Aktionen durch Klick auf ein Button ausgelöst. Ein Script im Hintergrund erfüllt dann die Aufgabe. Arbeitsabläufe lassen sich so besonders einfach erstellen. Bei einer wachsenden Applikation wachsen auch die Anzahl Scripts, bis es unter Umständen Hunderte Scripts gibt. Schnell wird so etwas unübersichtlich. Dabei bestehen viele Scripts oft nur aus ein paar Zeilen. Kann man dies vereinfachen?

Ja, man kann Scripts vereinfachen. Folgende Vorgehensweisen haben sich bei mir bewährt:

  1. Scripts möglichst pro Layout erstellen
  2. Scripts möglichst pro Tabelle gruppieren
  3. Verschiedene kleinere Scripts in einem Script zusammenfassen.

Die Basisidee soll immer sein, kleinere Einheiten zu erstellen, die man gut prüfen kann, um diese dann für grössere Aufgaben zusammenzufassen.

Alle Scripts mit Wenn-Abfragen steuern

Als Faustregel wird bei mir jedes Script mit einem Scriptparameter aufgerufen. Ruft man ein Script ohne Scriptparameter auf, dann geschieht gar nichts. Die Funktionalität steht immer in einer Wenn-Abfrage. Das erhöht nicht nur die Sicherheit, sondern erlaubt auch die Verwendung des einen Scripts für mehrere Aufgaben.

Viele Scripts erledigen nur kleinere Aufgaben. Beispielsweise habe ich oft eine Seite mit Einstellungen, die ich anpassen kann. Diese Einstellungen kann ich sichern und wieder einlesen. Problemlos lassen sich beide Aufgaben (sichern/einlesen) in einem einzigen Script unterbringen. Beispielsweise so:

In diesem Screenshot ist eine vereinfachte Darstellung. Ganz oben steht der Name des Scripts. Dort kann man noch mehr Informationen ergänzen, wenn man will. Darunter gibt es eine Liste mit allen Script-Parametern, womit das Script aufgerufen werden kann. Das dient der Übersichtlichkeit und ist gleichzeitig so etwas wie ein Index zum Script. Die Script-Parameter zeigen die Abschnitte im Script. Erst danach folgt die eigentliche Funktionalität.

  1. Script-Name
  2. Liste mit Script Parametern, womit das Script aufgerufen werden kann
  3. Die eigentliche Funktionalität in Wenn-Abfragen.

Jeder Abschnitt erscheint dann mit einer Wenn-Abfrage. Möchte ich beispielsweise in einem Script das Lesen und Schreiben von Voreinstellungen erledigen, könnte das Script so aussehen:

Wenn [ Hole ( ScriptParameter ) = “schreiben” ]
*** HIER DIE LOGIK ***
Ende

Wenn [ Hole ( ScriptParameter ) = “lesen” ]
*** HIER DIE LOGIK ***
Ende

Damit erhalte ich ein Script, womit ich verschiedene Aufgaben lösen kann. Das reduziert die Anzahl Scripts. Ich habe Scripts, die oft bis zu einem Dutzend kleinere Aufgaben erledigen. Das ist keine Vorgabe, sondern eine Möglichkeit, sich die Arbeit zu erleichtern.

Teilaufgaben nutzen

Mit dieser Vorgehensweise lassen sich Teilaufgaben sauber trennen und trotzdem zusammenhalten. Statt ein Script mit vielen Unterscripts zu nutzen, können die Aufgaben vielleicht in einem Script zusammengefasst werden. Jede Wenn-Abfrage kann eine Teilaufgabe sein. Das hält die Scripts übersichtlich und man kann Teilaufgaben nacheinander oder einzeln abrufen.

Teilaufgaben können auf zwei Arten aktiviert werden:

  1. Man ruft aus dem Script dasselbe Script mit einem anderen Parameter auf
  2. Man ergänzt eine Wenn-Abfrage mit einem weiteren Parameter, der dann weiter unten im Script aufgegriffen wird.

Zur zweiten Variante hier eine Erklärung: Selbstverständlich sollen Script-Parameter beim ersten Aufruf des Scripts gesetzt werden. Das hält jedoch nicht davon ab, im Verlauf des Scripts immer den nächsten Schritt anzugeben – beispielsweise mit einer Variablen.

Wenn [ Hole ( ScriptParameter ) = “schreiben” ]
*** HIER DIE LOGIK ***
Variable setzen [ $NextStep ; Wert: “output” ]
Ende

Hier wird am Ende einer Wenn-Abfrage eine Variable gesetzt mit dem Stichwort “output”. Diese Variable soll auf den nächsten Schritt mit dem Namen “output” hinweisen. Insofern dieser Abschnitt in einer weiteren Wenn-Abfrage enthalten ist, sollte nach dem Abschluss des ersten Abschnitts, nun der zweite Abschnitt aktiviert werden. Das kann man beispielsweise so machen:

Wenn [ Hole ( ScriptParameter ) = “output”  oder  $NextStep = “output” ]
*** HIER DIE LOGIK ***
Ende

Die Ergänzung bei der Wenn-Abfrage ist nun so formuliert, dass man diesen Teil entweder mit einem ScriptParameter oder mit einer lokalen Variable aus dem Script ansteuern lässt. So lassen sich in einem Durchlauf mehrere Abschnitte «abarbeiten», ohne, dass man das Script mehrfach abrufen muss.

Machen diese Angaben einen Sinn? Das ist vielleicht nicht nur eine Frage des Programmierstils, sondern hängt ebenso mit der Art von Projekten zusammen, wofür man arbeitet. Bei mir steht immer die Frage voran: «Wie halte ich alles so einfach wie möglich?».

Warum sollte man dies anwenden?

Nachdem ich den Text hier oben auf Social Media gepostet hatte, wurde die Frage gestellt «Warum sollte man dies anwenden?». Ich wurde mir bewusst, dass ich noch nichts über die Gründe gesagt hatte, wieso ich zu dieser Strukturierung kam. Dazu nun hier ein paar Worte:

Zuerst einmal ist es einfach eine (von vielen) Methoden, Scripts zu schreiben. Es sind keine Vorgaben. Bei mir waren es verschiedene Erfahrungen, die zu dieser Methode geführt haben:

Herausforderungen

  1. In grösseren Datenbanken hatte ich Hunderte Scripts. Viele davon waren nur ein paar Zeilen gross.
  2. Öfters hatte ich dieselbe Funktion an mehreren Orten integriert oder ich hatte mehrere Scripts dafür im Einsatz.

«Je grösser» bedeutete nun auch «desto unübersichtlicher». Deswegen hatte ich folgende Anliegen:

Optimierungswünsche

  1. Reduziere die Anzahl Scripts
  2. Vermeide Redundanzen bei den Funktionen
  3. Erleichtere die Gesamtstruktur aller Scripts
  4. Optimiere die Möglichkeiten jedes einzelnen Scripts.

Die Ideen einer modularen Entwicklung von FileMaker Funktionen zeigten mir auf, wie das möglich ist. Insbesondere folgende Ansätze erwiesen sich als hilfreich:

Umsetzung

  1. Gruppiere Scripts möglichst nach Tabelle / Layout
  2. Reduziere Scripts idealerweise auf die «eigenen» Tabellen / Layouts
  3. Fasse mehrere Funktionen pro Tabelle / Layout in einem einzigen Script zusammen
  4. Jedes Script hat so mehrere «Teile», die durch einen ScriptParameter angesteuert werden können.

Soll dies jetzt eine rigide Regel sein? Nein. Es hat bei mir jedoch alle Scripts vereinfacht und die Anzahl Scripts drastisch reduziert. Als Methode hat sich das bei mir bewährt.


Wie sich iPad und iPhone in FileMaker erkennen lassen

Wie sich iPad und iPhone in FileMaker erkennen lassen


10. Februar 2021In FM Starter, TippsBy Karsten Risseeuw1 Minutes

Erstellt man eine Datei für iOS-Geräte, muss man dort vermutlich unterscheiden können zwischen iPhone und iPad. Beim Starten der Datei muss man eine Abfrage erstellen, aufgrund dessen ein Layout für iPhone oder iPad angesteuert wird. Dies soll möglich sein mit der Statusabfrage:

Hole ( ProgrammVersion )

Läuft die Datei auf dem iPhone, ist das Resultat «Go», während es auf dem iPad das Resultat «Go_iPad» zurückmeldet. Eine komplette Abfrage lässt sich laut der FileMaker Hilfe wie folgt erstellen:

MusterAnzahl ( Hole ( ProgrammVersion ) ; “Go” ) für iPhone, und
MusterAnzahl ( Hole ( ProgrammVersion ) ; “Go_iPad” ) für iPad

Baut man diese Abfrage ein, zeigt sich, dass dies nicht gut funktioniert. Beide Anfragen erkennen nur ein iPhone. Das ändert sich auch nicht, wenn man statt “Go_iPad” nur noch “iPad” für die Mustererkennung eingibt.

Eine einfache Lösung besteht darin, lediglich für iOS zu suchen und dann pro Abfrage explizit das Gerät zu eruieren:

Hole ( Gerät ) = 4, für iPhone
Hole ( Gerät ) = 3, für iPad

Dies funktioniert tadellos.

Anpassung für FM Starter

Im nächsten Update von FM Starter wird dies für die Navigation angepasst. Wer das heute bereits anpassen möchte, muss dies hier anpassen:

Script: GN GetSystemLayout, line 25.

Let (
a = Get ( ApplicationVersion ) ;

Case (
PatternCount ( a ; “Pro” ) ; 1 ;
Get ( Device ) = 4 ; 2 ;
Get ( Device ) = 3 ; 3 ;
PatternCount ( a ; “Web” ) ; 4 ;
1 )
)


Ein eigenes Filemaker Pro Entwicklunssystem bauen

Baue Dein eigenes Filemaker Pro Entwicklungssystem

Wer als Filemaker Entwickler anfängt, wird vermutlich dieselben Fehler machen, die andere auch machen. Daran ist nichts falsch, und es hilft sogar dabei zu verstehen, auf was es wirklich ankommt. Man nennt dies «Erfahrung» und es ist ein zuverlässiger und bereichernder Weg, zu einem besseren Verständnis zu gelangen.

Es gibt verschiedene Gründe, weshalb Entwickler früher oder später nach einem System Ausschau halten. Dabei geht es nicht um bestimmte Konventionen, aber mehr um eine bestimmte Arbeitsweise. Man will wiederkehrende Aufgaben besser lösen, oder vielleicht einfach eine Startdatei zum Anfangen haben. Häufig gibt es mehrere Wege, die zu einer guten Lösung führen. Einige Wege sind aber effizienter als andere. Verbesserungen anzustreben heisst in der Regel, dass man bessere Ansätze verwendet und effizientere Methoden für bestimmte Herausforderungen findet, oder dass man allgemein den Arbeitsfluss verbessert.

FM Starter kann eine mögliche Variante sein, um schneller zum Ziel zu gelangen. Auch wenn die Lösung bei weitem nicht «perfekt» ist, löst sie doch eine Reihe von Herausforderungen womit sowohl ich selbst als auch andere jahrelang gerungen haben. Heute denke ich, dass FM Starter noch drastisch vereinfacht werden kann. Die Vereinfachung von Funktionen, von Abläufen, von Betrachtungsweisen ist vielleicht der grösste Wert, den man als Entwickler mitbringen kann. Die Bewältigung komplexer Aufgaben ist nämliche eine Sache, die Fähigkeit sie zu vereinfachen jedoch eine andere.

Ich habe grosse Bewunderung vor Entwicklern, die wirklich komplexe Aufgaben mit Bravour meistern. Komplexität ist manchmal vorgegeben, aber wenn etwas einfacher geht – weshalb dann nicht vereinfachen? Je besser man etwas versteht, desto leichter fällt es, den Arbeitsfluss oder die Programmierung zu vereinfachen. So kann eine Lösung oder System nicht nur erweitert, sondern auch tatsächlich verbessert werden. Arbeitsschritte können reduziert, vereinfacht und verkürzt werden. Zusammenhängende Abläufe werden vielleicht besser aus kleineren Teilen aufgebaut, oder – umgekehrt – vielleicht besser in einem einzigen Schritt erledigt. Wer es versteht komplexe Abläufe in einfacheren Schritten aufzuschlüsseln, hilft damit sich selbst und anderen, die Arbeit auch Jahre später nachzuvollziehen.

Wer ein System vor Augen hat, profitiert auf lange Sicht von einer möglichst einfachen Lösung. Konventionen und komplexe Regelwerke können nur wenige Menschen verarbeiten. Die Abgrenzung von einzelnen Abläufen schafft auf Dauer eine grosse Flexibilität – auch zur Verbesserung. «Reduce to the max» wäre hier die wegweisende Reduktion auf wenige gute Prinzipien, Arbeitsabläufe und Funktionen.

Beginnt man ein System aufzubauen, gilt es die eigene Arbeitsweise zu berücksichtigen. Haben Sie bewährte Vorgehensweisen? Oder suchen Sie nach neuen Möglichkeiten? Die aktuelle Lösungen werden mit Sicherheit künftig von noch besseren Lösungen abgelöst. Es spielt demnach keine wirkliche Rolle, womit man anfängt, solange man selbst zügig damit arbeiten kann. Bestimmte Ansätze werden sich bewähren, während andere mit der Zeit wieder verschwinden werden. Einige Anwender von FM Starter benutzen die Lösung wie sie ist, und bauen darauf auf. Andere wiederum benutzen FM Starter lediglich als Anregung, und implementieren diese oder jene Ideen in bereits bestehenden Lösungen. Es gibt hier kein Falsch oder Richtig. Pflanze einfach einzelne Bäume, und vielleicht hat man nach einigen Jahren einen eigenen Obstgarten.

Ein eigenes System

Hier einige Fragen zur Evaluation einer Starterlösung:

  • Was will ich vereinfachen?
  • Kann ich das selbst in nützlicher Frist?
  • Gibt es eine brauchbare Alternative, die mir den Weg verkürzt?
  • Was wäre am dringendsten zu realisieren?
  • Welche eigene Konzepte sind überholt und bedürfen einer Neuorientierung?
  • Wenn man die Prioritäten nach dem Grundsatz «Wichtiges vor Dringendes» einrichtet, was müsste man tun?