Hi zusammen,
das Thema meta.txt bzw. Verwaltung von Meta-Angaben zu Dateien kommt ja immer wieder auf, und der Grundtenor ist ja eigentlich, dass dies in TL unzureichend gelöst ist.
Ich möchte hier nur auf das Speicherformat der Meta-Angaben eingehen. Wie man eine Eingabeoberfläche für Metaangaben ins Backend integrieren kann, ist ein anderes Thema.
Aktuell werden Metaangaben zu Dateien ja in der meta.txt gespeichert. Diese hat folgendes Format:
Dieses Format ist ziemlich unflexibel. Es ist hauptsächlich für Bilddateien konzipiert (Titel = Caption, Link = Weiterführende Seite, Beschreibung = Lightbox-Unterschrift). Für Downloaddateien ist das Link-Argument z. B. in den meisten Fällen sinnlos*. Und was ist, wenn man für Bilddateien zusätzliche Informationen speichern möchte (wie z. B. die Bildmitte)?
Letzteres ist ohne weiteres bereits möglich: Die Parse-Funktion für die Meta-Datei trennt einfach den Paramter-String an den "|” auf und speichert die Bestandteile in einem Array ($meta[0] enthält somit den Titel, $meta[1] den Link etc.) – ein vierter Parameter wäre also mit $meta[3] abrufbar usw.
Da ergibt sich nur ein Problem:
Eine Erweiterung speichert zusätzliche Informationen, wie ein Vorschaubild, als vierten Parameter ab. Eine andere Erweiterung will den Namen des Users speichern, der das Bild hochgeladen hat. Woher weiß aber jetzt die eine Erweiterung, dass eine andere bereits den vierten Parameter mit seinen Informationen besetzt hat? Woher wissen Module, dass an Position vier eine Bild-URL und nicht ein Nutzer gespeichert ist? Und was passiert mit den bereits gespeicherten zusätzlichen Informationen, wenn die im o. g. Ticket genannte Änderung eingeführt wird?
Wie lösen wir das Problem? Da sehe ich zwei Möglichkeiten:
In einem Ticket hatte ich bereits eine Idee zu einem solchen neuen Format skizziert. Ich schlage die Benutzung einer JSON-ähnlichen Syntax vor, da diese sehr flexibel ist und nur einen – im Verlgeich zu anderen Formaten – sehr geringen Overhead besitzt sowie – und insbesondere – in gewisser Weise standartisiert ist. Ich nenne es mal JPL (JSON per line):
Die erste Zeile des Codeblocks enthält die allgemeine Syntax, die weiteren zeigen Beispiele. Der gesamte Codeblock ist eine valide "meta.jpl". Eine Implementierung von Listen (siehe Zeile 3, Schlüssel "keywords") kann auch – zwecks Vereinfachung des Parsers – umgangen werden (siehe Zeile 4). Es können beliebig viele Leerzeichen zwischen den einzelnen Syntaxelementen vorkommen. Die Eigenschaften können in beliebiger Reihenfolge auftauchen.
Vorteile dieses Formats:
Nachteile:
Probleme:
Nun zu euch:
Was meint ihr dazu?
Wie nötig findet ihr eine solche Änderung?
Wie sinnvoll findet ihr meinen Vorschlag?
Was schlagt ihr vor?
Was könnte man noch verbessern?
Wo liegen noch Probleme, Nachteile, Vorteile? (Ich erweitere die Listen oben dann.)
* In einer Downloadliste könnte ein Link zu einer Detailseite zum Download führen, in der der Inhalt ausführlich beschrieben wird.
das Thema meta.txt bzw. Verwaltung von Meta-Angaben zu Dateien kommt ja immer wieder auf, und der Grundtenor ist ja eigentlich, dass dies in TL unzureichend gelöst ist.
Ich möchte hier nur auf das Speicherformat der Meta-Angaben eingehen. Wie man eine Eingabeoberfläche für Metaangaben ins Backend integrieren kann, ist ein anderes Thema.
Aktuell werden Metaangaben zu Dateien ja in der meta.txt gespeichert. Diese hat folgendes Format:
Code:
[Dateiname].[Dateiendung] = [Titel] | [Link] | [Beschreibung]
Letzteres ist ohne weiteres bereits möglich: Die Parse-Funktion für die Meta-Datei trennt einfach den Paramter-String an den "|” auf und speichert die Bestandteile in einem Array ($meta[0] enthält somit den Titel, $meta[1] den Link etc.) – ein vierter Parameter wäre also mit $meta[3] abrufbar usw.
Da ergibt sich nur ein Problem:
Eine Erweiterung speichert zusätzliche Informationen, wie ein Vorschaubild, als vierten Parameter ab. Eine andere Erweiterung will den Namen des Users speichern, der das Bild hochgeladen hat. Woher weiß aber jetzt die eine Erweiterung, dass eine andere bereits den vierten Parameter mit seinen Informationen besetzt hat? Woher wissen Module, dass an Position vier eine Bild-URL und nicht ein Nutzer gespeichert ist? Und was passiert mit den bereits gespeicherten zusätzlichen Informationen, wenn die im o. g. Ticket genannte Änderung eingeführt wird?
Wie lösen wir das Problem? Da sehe ich zwei Möglichkeiten:
- Der vierte Parameter wird als serialisiertes Array "verallgemeinert". D. h. alle zusätzlichen Informationen in der Meta.txt werden in einem assoziativen Array gespeichert. Somit kommt es nicht zu einer Kollision von verschiedenen Parsern, denn man weiß immer, welche Information hinter den gegebenen Daten steckt.
Aber, wie ein anderer Nutzer sagte: Warum eine Krücke durch eine andere ersetzen? - Ein neues Datei-Metaangaben-Format, was flexible und eindeutige Angaben von Meta-Informationen zulässt.
In einem Ticket hatte ich bereits eine Idee zu einem solchen neuen Format skizziert. Ich schlage die Benutzung einer JSON-ähnlichen Syntax vor, da diese sehr flexibel ist und nur einen – im Verlgeich zu anderen Formaten – sehr geringen Overhead besitzt sowie – und insbesondere – in gewisser Weise standartisiert ist. Ich nenne es mal JPL (JSON per line):
Code:
{"[Dateiname].[Dateiendung]" : { "[Schlüssel1]" : "[Wert1]", "[Schlüssel2]" : "[Wert2]", […], "[SchlüsselX]" : "[WertX]" } }
{"bild.jpg" : { "title" : "Ein Beispielbild", "desc" : "Dieses Bild veranschaulicht etwas.", "url" : "https://contao.org/" } }
{"download1.zip" : { "title" : "Etwas zum Herunterladen", "keywords" : ["Stichwort 1", "Stichwort 2", "Stichwort 3"], "thumb" : "tl_files/thumbnails/download1.jpg" } }
{"download2.zip" : { "title" : "Etwas anderes zum Herunterladen", "keywords" : "Stichwort 1|Stichwort 2|Stichwort 3" } }
{"template.tar.gz" : { "title" : "Template herunterladen", "desc" : "Diese Datei enthält alle nötigen Dateien um die kostenlose Vorlage XYZ in Ihrer TYPOlight-Installation zu verwenden.", "thumb_list" : ["tl_files/thumbnails/template-1.jpg", "tl_files/thumbnails/template-2.jpg", "tl_files/thumbnails/template-backend.jpg"], "url" : "http://www.tl-templates.tld/templates/item/XYZ.html" } }
Vorteile dieses Formats:
- flexibel
- spezifische Meta-Angaben möglich
- geringer Overhead (also gutes Verhältnis von Syntaxelementen vs. Information)
- JSON ist (in gewisser Weise) ein Standard, weit verbreitet
- nativer JSON-Parser in PHP vorhanden!
- … sollte dieser deaktiviert sein, ließe sich leicht ein kleiner Parser selber bauen
Nachteile:
- größere Dateigröße als meta.txt-Format
- benötigt ein wenig mehr Rechenleistung und RAM als meta.txt-Format
Probleme:
- (Wahrscheinlich) keine Zeilenumbrüche in Angaben möglich.
Lösung: "<br />", "\n" und ggf. "\r" nutzen, um einen Zeilenumbruch zu erzeugen. - Abwärtskompatibilität?
Die Schlüssel "title", "desc" und "url" (bzw. "link") werden zusätzlich unter $meta[0] bis $meta[2] abgespeichert, sodass bisherige Erweiterungen / der Core ohne Änderung weiter funktioniert.
Wenn keine meta[_??].jpl vorhanden, wird eine meta.txt gesucht und geladen.
Nun zu euch:
Was meint ihr dazu?
Wie nötig findet ihr eine solche Änderung?
Wie sinnvoll findet ihr meinen Vorschlag?
Was schlagt ihr vor?
Was könnte man noch verbessern?
Wo liegen noch Probleme, Nachteile, Vorteile? (Ich erweitere die Listen oben dann.)
* In einer Downloadliste könnte ein Link zu einer Detailseite zum Download führen, in der der Inhalt ausführlich beschrieben wird.
) nicht sein ganzes Dateisystem nochmal in der DB gespiegelt haben – das riecht ja förmlich nach Datenchaos 
.
arseMetaFile()
Kommentar