Ronny Schrader

Seit einigen Wochen stecke ich einem Projekt bei dem die Dateneingabe über ein Web Front-End erfolgen wird. Da der Kunde die meisten Einstellungen selbständig durchführen möchte und ein jedes Datenfeld seine Bedeutung ändern wird, erschien mir IWP als die richtige Lösung für die Darstellung der Webseiten. Kein DreamWeaver oder anderer Editor wird im Nachgang bei Änderungen im Layout benötigt.

Was ist aber mit dem Import und Export von Datensätzen. Bei der Nutzung des IWP geht mit den Bordmitteln von FileMaker nichts. Kein Import oder speichern. Nach einigen Recherchen im Netz bin ich auf die Seite des Herrn Cristian Stüben geraten.

http://www.haifischbar.com

Nun ist es möglich Daten zu exportieren und zu importieren.

Gerade schau ich mir mal die Lösung von Jens Liebelt an.

http://www.jens-liebelt.de/fm-explorer/

Das Thema ist vielen FileMaker Entwicklern vertraut: Im Verlauf und insbesondere zum Abschluss eines Projektes einer Zusammenarbeit sind nicht nur viele Tabellen, sondern auch viele Dateien entstanden, die ich an meine Kunden weitergeben möchte. Gleiches gilt, will ich eine Demoversion meiner Software an neue Interessenten schicken. Im Allgemeinen gebe ich die Dateien oder Demoversionen dann als Runtime weiter. Die FileMaker Runtime liegt mit etlichen Dateien innerhalb eines Ordners. Was aber macht der Kunde mit einem Ordner voller Dateien?
Als Orientierungshilfe für den Anwender bieten sich mir zwei Möglichkeiten. Entweder füge ich einer Demoversion ein Dokument mit Erläuterungen zum Start der Datei bei, was potentielle Kunden allerdings schon im Vorfeld abschrecken könnte, oder ich investiere etwas Arbeit in die intelligente Verpackung meiner Demo-Software. Unter Windows konnte ich diese Problematik schon frühzeitig umgehen: Hier gibt es ein nahezu unendliches Angebot an Installationsprogrammen, mit deren Hilfe die Dateien an die richtige Stelle gelegt und entsprechende Menüeinträge zum Starten der FileMaker Runtime erzeugt werden können. Diese Möglichkeiten zur Installation gibt es auch unter Mac OS X, aber der Mac-Nutzer ist es nun einmal gewohnt, Applikationen aus dem .dmg-Image1 auf seine Festplatte zu ziehen und per Doppelklick zu starten.
Dies lässt sich ermöglichen, indem der Ordner mit den entsprechenden Dateien als Applikation gebündelt wird: nun kann die im Ordner liegende FileMaker Runtime Applikation mit dem vertrauten Doppelklick geöffnet werden. Sicherlich gibt es eine Vielzahl von Möglichkeiten, den Ordner mit einer Aktion zu verbinden. Eine der komfortabelsten ist für mich die Verwendung des Tools Platypus2. Dieses kleine „Schnabeltier“ verwandelt den Ordner mit den enthaltenen FileMaker Dateien in eine native Mac-OS-Applikation.
Werkzeuge
Für die Erstellung der FileMaker Runtime nutzen wir das in der FileMaker Advanced Version (bei FileMaker 7 heißt es Developer-Version) mitgelieferte Werkzeug – dies ist allerdings nur in der jeweiligen Entwickler-Version enthalten.
Als zweites Werkzeug verwende ich das bereits erwähnte Tool Platypus. Es dient der Bündelung von Scripts zu einer Applikation, eignet sich aber auch hervorragend zum Verpacken der FileMaker Runtime sowie der dazugehörenden Dateien. Der Quellcode steht unter GNU General Public License und die Nutzung ist kostenlos.
Um den Umfang der fertigen Applikation zu reduzieren, verpacke ich sie in eine Image-Datei (.dmg). Diese Image-Dateien enthalten oft eine Kurzanleitung und eine „Bitte lesen!“-Datei des Entwicklers und sind jedem Mac-Nutzer bekannt. Enthaltene Programme bzw. Applikationen werden per „drag and drop“ in das Pro- grammverzeichnis gezogen.
Für die Erzeugung von Image-Dateien gibt es ebenfalls ein vielfältiges Angebot an Werkzeugen. Die einfachste Möglichkeit ist die Nutzung des Festplatten-Dienstprogramms, das mit Mac OS X geliefert wird. Hat man das Programm gestartet, kann unter Ablage ̈ Neu ̈ Image von Ordner die Applikation zum Image konvertiert werden. Mein persönlicher Favorit ist aber FileStorm, denn mit dieser Applikation kann ich der Image-Datei zusätzlich eine persönliche Note verleihen: So lassen sich z. B. der Hintergrund und das Image-Symbol individuell gestalten.
Aufbau einer Mac OS Applikation
Eine Applikation unter Mac OS X besteht aus verschiedenen Verzeichnissen, die Struktur kann man sich im Finder anzeigen lassen. Mit einem Rechtsklick auf die Applikation oder über den Menüpunkt Paketinhalt anzeigen im Kontextmenü wird die Verzeichnisstruktur sichtbar. Üblicherweise entspricht sie folgen- dem Schema:
Applikationsname.app/Contents/Info.plist
Applikationsname.app/Contents/MacOS/executable
Applikationsname.app/Contents /Resources/icon.icns
Applikationsname.app/Contents /Frameworks/
Applikationsname.app/Contents/PlugIns/ Erstellung der Runtime
Grundsätzlich unterscheidet sich die Erstellung einer Runtime unter Windows nicht von der unter Mac OS X. Zu bedenken ist aber, dass die Projektdateien ProjektXY.sav der beiden Systeme nicht kompatibel sind. Das bedeutet: Wenn ich meine FileMaker Dateien kompatibel für beide Systeme entwickeln möchte, muss ich spätestens bei der Runtime-Erstellung zwei Versionen anlegen.
Der Aufruf der Funktion erfolgt im FileMaker Menü unter Werkzeuge ̈ Entwicklungs- werkzeuge. Hier können Sie die gewünschten Dateien auswählen, die Startdatei vorgeben und einige Parameter wie Projektordner, Abschlussbild u. ä. festlegen. Dabei sollten Sie auf jeden Fall darauf achten, unterschiedliche Projektordner für Mac OS und Windows aus- zuwählen. Warum betone ich die verschiede- nen Projektordner so ausdrücklich? Ich arbeite ausschließlich am Mac und starte Windows über Parallels. Als Besonderheit von Parallels ab Version 4 an gilt: Ab dieser Version könnten die Mac- und Windows-Dateien auch in einem Projektordner liegen, da die beiden Betriebssysteme sich völlig mischen und nicht mehr zwischen Verzeichnissen für Mac oder Windows unterschieden werden muss. Dies führt aber bei nur einem Projektordner zu ei- ner Überschreibung der für Windows erzeug- ten Dateien und umgekehrt.
Der Rest der Runtime-Erstellung ist selbst- erklärend und soll nicht Thema dieses Beitrags sein. Noch zu erwähnen ist, dass nach der Erstellung der Runtime mindestens eine FileMaker Applikation mit der Datei-Endung .app und die eigentliche FileMaker Datei mit der standardmäßigen Datei-Endung .USR im Projektordner liegen.
Erstellung des Application Bundles unter Mac OS
Nachdem Sie die Runtime-Datei erstellt haben, können Sie den kompletten Projekt- ordner zu einer Applikation bündeln. Dazu benötigen Sie das bereits erwähnte Tool Platypus.
Nach dem Programmstart öffnet sich ein kleines Fenster mit relativ wenigen Einstellun- gen:

Für mich sind nur die Einstellungen von Platypus relevant, die ich für meine FileMaker-
Bundles benötige. Daher gebe ich hier nur einen relativ kleinen Einblick in die Fähigkeiten dieses Programms. Wer weitergehende Ambitionen hegt, sollte sich das Programm ruhig genauer anschauen.
Für unsere Zwecke sind nur wenige Angaben notwendig: In das Feld „App Name“ schreiben Sie den Titel Ihrer Applikation. In meinem Fall lautet der Titel „DokuCare“. Als „Script Type“ wählen Sie „AppleScript“. Im Feld „Script Path“ befindet sich der Pfad zu einem AppleScript, das die Anweisung dafür enthält, was bei einem Klick auf die fertige Applika- tion geschehen soll. Deshalb haben Sie auch im vorhergehenden Feld für den „Script Type“ das Format „AppleScript“ gewählt. Platypus vervollständigt automatisch den Pfad zum Interpreter.
Jetzt müssen Sie nur noch ein kleines Apple- Script schreiben. Es besteht aus zwei Anweisungen: 
Tell application „Application“
Über wird die FileMaker Applikation (Pflegeverwaltung.app), die im Runtime-Ordner liegt, angesprochen und geöffnet. Über den Befehl 
„to activate“
wird das FileMaker Applikationsfenster in den Vordergrund geholt. Da nun Ihre FileMaker Applikation gestartet ist und sich im Vordergrund befindet, schließen wir die im Verzeichnis Applikationsname.app/Contents/MacOS liegende ausführende Datei DokuCareFM. Diese wird auch als „executable“ (ausführbar) bezeichnet und startete die FileMaker Applikation (Pflegeverwaltung.app). Geschlossen wird über die Anweisung
quit application „Application“ 

Das bedeutet, Sie schreiben in einen Editor Ihrer Wahl den Befehl:
Danach schreiben Sie
und speichern die Datei im Projektordner als Applikation.scpt.
Jetzt selektieren Sie nur noch den Pfad zum neu erzeugten AppleScript im Feld „Script Path“. Die besten Erfahrungen bei der Benennung des AppleScript habe ich damit gemacht, dass das Script den Namen der Applikation erhält, denn sobald der Name aus dem Feld „App Name“ sich von der Bezeichnung des App- leScript unterscheidet, startet die von Ihnen er- stellte Applikation nicht mehr zuverlässig. Am einfachsten ist es, das Feld App Name leer zu lassen, da es dann automatisch mit der Bezeich- nung des AppleScript gefüllt wird.
Wenn Sie innerhalb Ihrer Datenbanken eigene Symbole einsetzen, möchten Sie wahrschein- lich auch hier ein themenbezogenes eigenes Icon verwenden. Ändern Sie dazu einfach das Symbol im entsprechenden Feld. Jetzt können Sie den Projektordner per „drag and drop“ in das Feld „Files and folders“ ziehen. Dann star- ten Sie über den Button „Create“ den Prozess der Bündelung. Das Programm Platypus er- fragt noch den Speicherort der zu erstellenden Applikation und beginnt dann mit der Arbeit. Ein visuelles Feedback über den Fortschritt der Erstellung gibt es nicht, lediglich der Button „Create“ bleibt bis zum Ende der Erstellung blockiert. Nach Abschluss erhalten Sie eine fertige Applikation mit eigenem Icon und der folgenden Dateistruktur:
Erzeugung der Image Datei
Um nun Ihre neu erstellte Applikation übers Internet zur Verfügung zu stellen, bietet es sich an, die Datei noch in ein Image zu verpacken.


Wie bereits erwähnt, besteht die Möglichkeit, Image-Dateien mit Bordmitteln zu erzeugen. Ich persönlich verwende hierzu aber das kostenpflichtige Tool FileStorm3. Mit FileStorm habe ich die Möglichkeit, der Image-Datei ein individuelles Aussehen zu geben – passt außer- dem vom Namen her sehr gut zum Produkt FileMaker!
Die Erzeugung der Image-Datei ist recht simpel: Zunächst erstellen Sie ein neues Pro- jekt. Anschließend öffnen Sie den Menü- punkt „Preferences“. Im geöffneten Fenster „FileStorm Preferences“ geben Sie unter dem Punkt „Defaults“ die individuellen Eigenschaften der Image-Datei ein. Das Fenster mit den „Preferences“ können Sie jetzt wieder schließen. Dann klicken Sie auf das Symbol „Inspector“.
Es öffnet sich das Fenster „Property Inspector“. Mithilfe der Tastenkombination + kom- men Sie in den Bereich „License Agreements“. Hier können Sie eine Lizenz-Datei angeben. Wenn später das Image entpackt wird, wird diese Lizenz angezeigt, und der Entpackungs-Prozess läuft erst nach Zustimmung durch den Anwender weiter. (Warum die Einstellung so versteckt liegt, weiß wahrscheinlich nur der Programmautor von FileStorm …)
Als Letztes ziehen Sie die von Ihnen zuvor er- stellte Applikation DokuCareFM.app per „drag and drop“ auf das Hauptfenster von FileStorm. Auch hier bietet es sich an, eine Kurzanleitung für die Applikation mit in das Fenster zu ziehen. Ein Klick auf den Button „Finalize“ erzeugt dann das Image.
Wie Sie nach dieser kurzen Abhandlung sehen können, ist der Aufwand für die Applikations-Erstellung zwar gering, aber doch etwas lästig. Sie erleichtern damit aber potentiellen Kunden den Zugang zu Ihrem Produkt und verringern Ihren Zeitaufwand für Supportleistungen, gerade für nicht programminhaltliche Fragen in erheblichem Maß.

Mailing mal anders
E-Mail-Verwaltung ganz ohne Plugin
Web Viewer als E-Mail-Zentrale
Während meines letzten Projektes bekam ich die Aufgabe, E-Mails kontextabhängig in FileMaker zu archivieren. Dabei stolperte ich über die fehlende Möglichkeit, E-Mails per drag and drop aus Outlook in ein FileMaker Feld zu ziehen. 

Eine Zwischenlagerung innerhalb eines temporären Ordners kam für den Auftraggeber nicht infrage. Mein erster Lösungsansatz war, die E-Mails über ein Plugin abzufragen und per Selektierung zuzuordnen, was über ein Plugin wie Mailit 4 recht einfach zu bewerkstelligen ist. Da aber noch keine Klärung des Arbeitsplatzumfanges stattgefunden hatte, war die finanzielle Kalkulation für den Auftraggeber schwierig.
Warum nicht ganz anders?
Da ich schon seit vielen Jahren keinen eigenen Exchange-Server betreibe sondern auf die massenhaft angebotenen Hostingversionen zurückgreife, komme ich natürlich auch mit der Webversion von Outlook (OWA) in Kontakt. Beim Abrufen meiner E-Mails per OWA kam mir irgendwann ein Gedanke: Warum nicht die Weboberfläche einfach im Web Viewer darstellen? Diese Idee sofort in die Tat umsetzend habe ich einen Test durchgeführt, der viel versprechend verlief: Die Oberfläche wurde problemlos angezeigt. 
Was soll ich speichern?
Nun ist es zwar nett, sich den Inhalt einer E-Mail im Web Viewer anzeigen zu lassen, aber es bringt noch keinen echten Mehrwert gegenüber dem Anblick einer E-Mail im Webbrowser. 
Mein erster Ansatz war es, den Inhalt des Web Viewers und somit die E-Mail als PDF-Datei zu speichern und in ein Medienfeld zu legen. Das geht schnell und ist mit FileMaker Bordmitteln machbar. Allerdings war ich von dieser Methode noch nicht vollständig überzeugt.

Ein Blick in das URL-Feld eines Browsers drängt einem die Lösung richtiggehend auf: Jede E-Mail besitzt eine eigene URL, die nur noch abgefragt werden muss. Speichere ich die URL in FileMaker, so kann ich die URL natürlich auch in FileMaker anzeigen lassen. Die Abfrage der URL erfolgt entweder über ein Script oder ein Formelfeld 

LiesLayoutobjektAttribut ( “Web Viewer 1”; “Quelle”)



Das Problem der unvollständigen URL
Wer schon mit der OWA-Oberfläche des Exchange-Servers gearbeitet hat, weiß sicherlich, dass es zwei unterschiedliche Arten der Darstellung gibt: Da haben wir zum einen die moderne Web-2.0-Oberfläche, die keinen Komfort vermissen lässt, und zum anderen die klassische Standardoberfläche, in der ein Link noch wie ein Link aussieht und sich auch wie einer verhält. 

Leider wird bei der Web-2.0-Oberfläche keine komplette URL mehr angezeigt, weshalb nach der Abfrage nur die URL der Hauptansicht gespeichert wird. Das lässt sich aber sehr einfach durch das Zurückschalten auf die alte Oberfläche umgehen. Jetzt bekommt FileMaker alle Links angezeigt und kann diese abfragen und speichern. Übrigens ist kein teurer Hosted Exchange Account nötig – ein einfacher Webmailer entweder vom Hoster oder auch in den eigenen Räumen (Horde, RoundCube o. Ä.) tut es auch. Da diese Mailer die günstigste Möglichkeit darstellen, E-Mails zu archivieren, habe ich meinen Beitrag darauf abgestimmt und den Webmailer RoundCube verwendet. 

Die Darstellung der E-Mails
Die Darstellung der E-Mails ist natürlich Geschmackssache. In meiner Anwendung habe ich ein Portal für die Daten der URL und ein Web-Viewer-Feld erstellt. Die Web-Viewer-URL ist auf eine Variable gelegt. Wird nun im Portal der Link gewählt, wird dieser an die Variable übergeben. Die E-Mail ist nun zu erkennen.
Um die Elemente des Webmailers bequem bedienen zu können, werden die E-Mails in einem Extrafenster gespeichert, das bei Bedarf auch auf einen anderen Monitor verschoben werden kann.



Der eigentliche Ablauf
Speicherung einer E-Mail
Soweit die Theorie. Die Umsetzung in der Praxis stellt jedoch keine große Herausforderung dar sondern lässt sich ganz einfach bewerkstelligen: Wir benötigen lediglich eine Tabelle, die neben den üblichen in der Praxis benötigten Feldern ein Formelfeld und ein Textfeld zum Speichern der URL enthält. 

Das Formelfeld ist wie folgt definiert 

LiesLayoutobjektAttribut ( “Web Viewer 1”; “Quelle”)

und in den Speicheroptionen muss das Häkchen bei „Ergebnisse nicht speichern – nur bei Bedarf neu berechnen“ gesetzt werden. Nun müssen wir nur noch ein Layoutelement mit der Bezeichnung „Web Viewer 1“ vom Typ Web Viewer in unserem Layout einbauen – und fertig. 

In meiner Anwendung habe ich das Web-Viewer-Element in ein Extrafenster verbannt, um mehr Platz zum Lesen der E-Mails zu haben. Diesem habe ich auch noch ein Feld zum Eingeben der URL zum Webmailer spendiert.

Möchte ich nun eine E-Mail speichern, so erzeuge ich per Script einen neuen Datensatz. Das Formelfeld ermittelt die URL, die im gleichen Script per „Feldwert setzen“ in unser Textfeld geschrieben wird. Und schon ist unsere E-Mail gespeichert – immer vorausgesetzt natürlich, es besteht eine Verbindung zum Webmailer.

Anzeigen einer E-Mail
Um die gespeicherte E-Mail bei Bedarf wieder anzeigen zu können, benötigen wir ein zweites Layoutelement vom Typ Web Viewer. Die URL hinterlegen wir als Variable oder auch als Formel. In meinem Beispiel habe ich auf der linken Seite eine Liste der URLs in einem Portal und auf der rechten Seite befindet sich der Web Viewer. Selektiere ich nun einen Datensatz innerhalb des Portals, so wird die Variable des Layoutelements gesetzt und die E-Mail wird im Web Viewer angezeigt.




Fazit
So einfach das Prinzip auch ist, so umfangreich und vielfältig sind die Möglichkeiten. Ich kann den E-Mail-Verkehr nun problemlos verschiedenen Projekten, Firmen oder Kontakten zuordnen. Wer sich daran stört, dass die E-Mails nicht offline zugänglich sind, der sei abschließend noch auf zwei Dinge hingewiesen: zum einen werden immer mehr Inhalte ins Web verschoben und zum anderen kommt die aufgezeigte Möglichkeit sicherlich nicht für jedes Projekt infrage.