_type h4 content Die Ausgangslage _type p class FloatText content Auf einem Rechner befinden sich zahlreiche Dateien, die irgendwelche Dokumente, Konfigurationen, Einstellungen usw. usf. enthalten. Jede diese Datei wird von einem oder mehreren Programmen geschrieben bzw. gelesen. Jedes Programm kann dabei grundsätzlich selbst bestimmen, wie diese Daten formatiert sind. _type p class FloatText content Das Chaos ist perfekt! _type p class FloatText content Dabei bestehen diese Daten fast immer aus den ewig gleichen Elementen. Da haben wir Zahlen, da haben wir Texte, da haben wir (kalendarische) Daten usw. Und auch die Verbindung dieser Daten ist meist recht langweilig: Arrays und Dictionarys. Im Grunde genommen unterscheidet sich ein Dateiformat von der anderen nur durch die Anordnung der Elemente, nicht aber durch die verwendeten Elemente. Das ist sogar unabhängig von der verwendeten Programmiersprachen nebst Framework. Auch ein C-Programm speichert Texte, Zahlen usw. in Arrays und Dictionarys. Auch ein PHP-Programm macht dies so, wenngleich Arrays nur ein Unterfall von Dictionarys sind. _type p class FloatText content Also liegt es nahe, allgemeine Elemente anzubieten, die man beliebig kombinieren kann. Dann müsste eigentlich ja eigentlich alle Daten eines Programms mit diesen Elementen darstellen können. Wenn man diese Daten dann auch noch in einem einheitlichen Format speichert, könnte man sie nicht nur austauschen, sondern auch noch allgemeine Editoren anbieten, um diese zu bearbeiten. Klingt praktisch. Das hat einen Grund: Es ist praktisch. _type p class FloatText content Formulieren wir also die Anforderungen an eine derartige Datenstruktur: _type p class FloatText content 1. Sie muss Standard-Elemente für die klassischen Datentypen implemmentieren. _type p class FloatText content 2. Es müssen die "klassischen" Collections Array und Dictionary vorhanden sein. _type p class FloatText content 3. Die Implementierung der Elemente muss unabhängig von einer Programmiersprache oder einem Framework erfolgen. _type p class FloatText content 4. Die Datenstruktur muss gespeichert und gelesen werden können. _type p class FloatText content 5. Die Handhabung muss einfach sein. _type h4 content Property-Lists und XML _type p class FloatText content Ich habe einige Diskussionen erlebt, die Property-Lists und _inline _type a content _inline _type nobr content ▹  XML href http://de.wikipedia.org/wiki/XML target _blank vergleichen. Leider stößt man darauf immer wieder auf dieselben Vorurteile. Am Ende des Tutorials wird hoffentlich klar sein, dass eigentlich dieser Vergleich schon schräg ist. Ein paar Worte aber schon hier: _type p class FloatText content Die XML (Extensible Markup Language, Erweiterungsfähige Auszeichnungssprache) beschreibt vereinfacht gesagt ein Format für die Persistenz von Dokumenten. Es geht hier aber nicht um ein konkretes Format, sondern nur um das Skelett. Man spricht daher auch gerne davon, dass XML eine Metasprache sei. In der Denke eines Programmierers kann man das vielleicht mit der Syntax einer Programmiersprache vergleichen. _type p class FloatText content Schon der Inhalt dieser Struktur ist indessen nicht definiert. Dies geschieht über eine so genannte _inline _type a content _inline _type nobr content ▹  DTD href http://de.wikipedia.org/wiki/Dokumenttypdefinition target _blank (Document Type Definition, Dokumententypdefinition), die festlegt welche einzelnen Elemente in einem XML-Dokument auftauchen dürfen. Bleibt man im obigen Bild, so enthält die DTD eine Sammlung von Klassendefinitionen, die für ein bestimmtes Dokumentenformat zulässig sind. _type p class FloatText content In einem konkreten Dokument sind diese in der DTD definierten Elemente in der Syntax von XML enthalten. Vergleich zur Programmiersprache: Instanzen. alt - class IsolatedCenterImage src ##page##XML-DOM.png type img _type p class FloatText content Dieses Triumvirat aus XML, DTD und konkretem Dokument beschreibt die Daten unabhängig von einem äußeren Kontext. Das einzige topologische Element ist der Umstand, dass eine Baumstruktur besteht, bei der jeder Knoten einen Namen (tag) hat, über Attribute verfügt und Daten enthält. Dem entsprechend liefert ein XML-Scanner als Ergebnis auch einen Baum aus so genannten XML-Nodes (Knoten). Die lesende Applikation muss diesen dann in die eigene Datenstruktur übersetzen, also für jeden Knoten eine entsprechende Instanz einer Klasse erzeugen (ugs: DOM-Style). Ein anderes System besteht darin, dass der Scanner ein Delegate das soeben gelesene Element mitteilt und dieses im Vorbeiflug entsprechende Instanzen erzeugt (ugs: SAX-Style). Aber es bleibt immer dabei: Nach dem Lesen – also der Umwandlung der seriell persistierten Datei in eine Struktur zur Laufzeit – muss eine weitere Umwandlung dieser abstrakten "XML-Struktur" in die konkrete Struktur des Applikations-Modelles erfolgen. _type p class Commentary content _type em content Cocoa bietet übrigens Klassen für das Scannen von XML-Dokumenten. _type p class FloatText content Property-Lists – und das verfeinern wir etwas später – definieren dagegen gar kein Dokumentenformat. Genau genommen haben sie nicht einmal etwas mit Dateien zu tun. Sie nehmen exakt das andere Ende des Definitionsstapels auf: Sie definieren inhaltlich Elemente, aus denen eine Property-List gebaut werden kann. Wie diese persistieren, interessiert gar nicht. Ganz im Gegenteil: Apple sagt ausdrücklich, dass man bitte nicht schauen soll, wie das ganze auf der Platte landet. Nehmen wir hier ein einfaches Beispiel: Den String. Es handelt sich um ein Element, welches eine Property-Lists bildet. (Ja: "bildet" – Darauf komme ich noch zurück.) Das ist festgelegt, nicht ein Tag, welches den String einleitet, sondern das Element String selbst. Jeder String, den Sie in einem Programm zusammenschrauben, ist eine Property-List. Noch einmal: Ein String lässt sich nicht als Property-List speichern, sondern er ist eine Property-List. _type p class FloatText content Dabei ist allerdings String als abstrakter Begriff zu verstehen. Der Property-List Reader von Cocoa erzeugt daraus eine Instanz von _inline _type code content NSString . Der Reader der Core-Foundation liefert ein CFString zurück. Mein PHP-Skript auf dieser Seite liefert eine Variable zurück, die eine Zeichenkette enthält usw. usf. Mit anderen Worten: Die Definition von Property-Lists legt inhaltliche Elemente fest. _type p class Commentary content _type em content Wir haben es also mit einer ganz anderen Schicht der Definition zu tun. Property-Lists unmittelbar mit XML zu vergleichen, ist daher so, als ob man ein Gemälde mit einem Pinsel vergleichen würde. Dass dies Anfänger dennoch häufig tun, hängt damit zusammen, dass man Property-Lists speichern kann und dies auch noch als XML-Datei. Häufig genug wird auch in Diskussionen der Begriff "Property-List" für genau dieses Property-List-XML-Format gebraucht. Das ist umgangssprachlich üblich, darf aber nicht darüber hinwegtäuschen, dass Property-List eigentlich ein abstrakt-logischer Begriff ist. _type h4 content Verwendung von Property-Lists _type p class FloatText content Das Einsatzgebiet von Property-Lists ist kaum zu überschauen, da sich letztendlich beliebig Daten speichern lassen. Einige Beispiele: _type p class FloatText content • _inline _type a content _inline _type nobr content ▹  launchd href http://launchd.macosforge.org/ target _blank verwendet Property-Lists für seine Konfigurationsdatei. _type p class FloatText content • Das _inline _type a content _inline _type nobr content ▹  Defaultssystem href http://developer.apple.com/documentation/Cocoa/Conceptual/UserDefaults/UserDefaults.html target _blank verwendet Property-Lists zur Speicherung der Applikations-Einstellungen. _type p class FloatText content • iTunes _inline _type a content _inline _type nobr content ▹  verwendet Property-Lists href http://docs.info.apple.com/article.html?artnum=93732 target _blank zum Export der Titelliste. _type p class FloatText content • Diese Seite _inline _type a content _inline _type nobr content ▹  speichert die Artikel href http://www.cocoading.de/Areas/Tutorials/Article5/Page0/article.plist target _blank als Property-Lists. _type h4 content Arbeiten mit Property-Lists _type p class FloatText content Da Property-Lists Elemente definieren, aber nicht ein Datei-Format, sollte es in einer idealen Welt so sein, dass man Property-Lists nie mit einem Texteditor anschaut. Das wäre sozusagen mal wieder haarscharf am Grundgedanken vorbei. _type p class FloatText content Viele Programme, die ihre Daten in Property-Lists organisieren haben bereits ein irgendwie geartetes User-Interface: laund hat _inline _type a content _inline _type nobr content ▹  launchctl href http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/launchctl.1.html target _blank , Defaults haben _inline _type a content _inline _type nobr content ▹  defaults href http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/defaults.1.html target _blank , iTunes hat seine GUI, die Artikel auf dieser Seite schreibe ich mit einem dahin gefrickelten Minimalprogramm. _type p class FloatText content Wenn Sie dennoch selbst an die Property-List-Datei Hand anlegen wollen, benutzen Sie keinen Texteditor. Das zeichnet Sie gleich als OS-X-DAU aus. Mit den Developer Tools wird ein einfacher Property-List-Editor mitgeliefert. Daneben gibt es noch _inline _type a content _inline _type nobr content ▹  PList Edit Pro href http://www.fatcatsoftware.com/plisteditpro/ target _blank . Zwar auch nicht gerade die Welt, aber gut zu gebrauchen. _type p class Commentary content _type em content Vielleicht schreiben Sie mal einen schönen Property-List-Editor? Man kann viele Technologien von Cocoa dabei gut trainieren.