Neue Funktionen für export

Ich generiere für meine Musik/Hörbuch-Sammlung verschieden Web-Darstellungen mit eigenen export-Skripten. Dabei vermisse ich schmerzlich folgende zwei Funktionen:

  1. if_exist(file,...[,...]) oder so ähnlich, also eine Funktion, die eine Ausgabe triggert, je nachdem ob die angegebene Datei existiert oder nicht. Eine typische Anwendung ist das Generieren eines Links auf eine Cover-Rückseite, die man aber nicht für alle CD's zur Verfügung hat. Das Einbetten diese weiten Covers vermeide ich, weil etliche Player Probleme haben, wenn mehr als ein Cover eingebettet wurde.

  2. include_file(file) oder so ähnlich, also eine Funktion, die den Inhalt einer Datei eins zu eins in den Ausgabestrom an der angegebenen Stelle übernimmt, wenn diese existiert. Manchmal habe ich spezielle Zusatz-Informationen zu CD's, die ich in einer Datei aufbewahre und nicht einbette, die ich aber in bestimmten Web-Darstellungen mit anzeigen möchte. Wo es geht, löse ich das Problem derzeit mit Server-Side-Includes, die man aber nicht bei jedem Web-Anbieter zur Verfügung hat.

Was mein ihr dazu?
Danke, Peter

Wie exportierst du denn bislang Covers im Rahmen eines Exports?
Dafür kenne ich gar keine Funktion.
Wäre es da nicht genauso sinnvoll, abgestimmte Export-Scripts zu haben, die je nach Gegenwart eines Covers in einer Audiodatei einen bestimmten Code erzeugen?
Da du den Export auch über Aktionen steuern kannst, wäre eine Aktionsgruppe möglich, die dann auch gleich das zugehörige Cover exportiert.
Und nach der Existenz eines Covers in einer Datei kann man filtern.

Da liegt ein Missverständnis vor, ich will kein Cover exportieren. Meine MP3-Dateien enthalten das Frontcover. Das Front- und ggf. vorhandenes Rückseitencover liegen im Verzeichnis der CD unter bestimmten Namen.
Mit einem Export-Skript generiere ich eine HTML-Datei, die Links auf diese
Dateien enthalten soll, allerdings will ich den Link auf die Rückseite nur generieren, wenn die Datei auch existiert. Wenn ich das Rückseitencover eingebettet hätte, wäre das kein Problem, aber aus oben genannten Gründen möchte ich das nicht tun.

Der sicherste Weg, diesen Umstand zu kontrollieren, ist nun mal, die Datei einzubetten.
Nur damit kannst du den Typ festlegen.
Dann exportierst du sowohl Datei also auch Skript, dann kannst du so viele eingebettete Cover löschen wie du willst, damit die wieder mundgerecht für den Abspieler sind und dann, damit die Sammlung wieder vollständig ist, auch wieder aus den Verzeichnissen importieren zum Einbetten.
Das ist zwar nicht der eleganteste Weg, aber eine Kette von Funktionen, die man tw. auch automatisch in den Arbeitsablauf einbauen kann.
Der Test auf Existenz einer Datei kann entfallen, wenn man sie zuvor gerade exportiert hat und somit weiß, dass sie da ist.
Auch stellt nur der aktuelle Export sicher, dass nicht noch alte, ggf. nicht passende Dateien für gut befunden werden.
Du wolltest eine Meinung:

Dies ist meine Meinung. Vielleicht gibt es ja noch andere.

Wenn ich meine HTML-Dateien neu generieren möchte (z.B. weil ich das Layout geändert habe), müsste ich die entfernten Rückseitencover zuvor automatisiert wieder einbetten,. Das geht zwar, belohnt mich aber mit "tausenden" Fehlermeldungen, nämlich immer dann, wenn keines existiert. Die Import-Aktion hat leider keinen Schalter für das unterdrücken der Fehlermeldung, wenn die Datei nicht existiert.

Da du dir selbst bestimmte Rahmenbedingungen vorgibst, kannst du diese auch erweitern - und ein benutzerdefiniertes Feld (z.B. cover_da)anlegen, in dem die Typen der mal eingebetteten Bilder festgehalten werden. In dem Feld könnte also z.B. stehen
front_back
Und mit Filter importierst du erst für die Dateien, wo
%cover_da% HAS front
Treffer liefert, dann wo
%cover_da% HAS back
Treffer liefert.
Voilà: keine Fehlermeldung - wenn zuvor die Typen richtig im Feld protokolliert wurden.
Das mag alles nicht so ganz stromlinienförmig sein, aber es ist schon mit den bestehenden Mittel zu erreichen.
Der Inhalt dieses Feldes kann dann auch im Export verwendet werden, statt der Prüfung von Objekten im Dateisystem.
Und diese Überlegungen haben, soweit ich weiß, keinen Einfluss darauf, ob dein Vorschlag umgesetzt oder erstmal vertagt wird.