Diskussion 🧙
Metadaten automatisch laden
Allgemein hinterlegte Metadaten könnten automatisch geladen und genutzt werden, als stünden sie in der aufgerufenen Aneamaldatei. Sinnvoll wäre das insbesondere für Metadaten, die auf vielen oder allen Seiten eingesetzt werden – eine Javascript-Funktion vielleicht, eine Autorenangabe, ein Feed, Icons, … So müssten die Angaben nicht mehr in zahlreichen Dateien wiederholt werden bzw. wären auch Leuten zugänglich, die sich nicht an PHP in aneamal-config.php herantrauen oder heranmachen wollen.
Siehe auch
https://prlbr.de/projekt/aneamal/diskussion/code-in-html-head-einfuegen#K4
https://prlbr.de/projekt/aneamal/diskussion/code-in-html-head-einfuegen#K7
https://prlbr.de/projekt/aneamal/diskussion/code-in-html-head-einfuegen#K8
https://prlbr.de/projekt/aneamal/diskussion/code-in-html-head-einfuegen#K9
als Ursprung dieser Diskussion.Ich denke, für dieses Thema gibt es einige Feinheiten zu klären, etwa die Vorrangregelung, wenn in einem Ordner die Dateien
<> @header.nml
<> @meta.nml
<> beispiel.nml
<> kopf.nmlliegen und in @meta.nml (automatisch geladene Metadaten) dann drinsteht:
@header: ->kopf.nml
Welche Datei wird dann als Header geladen – @header.nml oder kopf.nml?
Eine mögliche Lösung könnte so aussehen, dass in @meta.nml die Angaben @header, @footer, @look und @aside nicht gesetzt werden dürfen. Das würde auch vermeiden helfen, dass man die Übersicht verliert, wo zum Beispiel ein @header gesetzt wurde, den man auf einer Seite sieht.
Eine Frage in eine ganz andere Richtung: Schön ist ja, dass man bei dieser Lösung weniger in PHP mit aneamal-config.php abtauchen müsste. Ließe sich aneamal-config.php eventuell ganz durch eine solche Lösung ersetzen, ggf. wenn noch ein paar zusätzliche, kleine Änderungen vorgenommen werden?
Ergänzung zu @2:
„Welche Datei wird dann als Header geladen – @header.nml oder kopf.nml“ – wenn beispiel.nml aufgerufen wird?
Naja, man kann mit mehr Modulen kombinatorisch mehr Unfug machen. Bei ahead, head, style, footer, meta sind es wenigstens n! Möglichkeiten.
Ich denke es macht Sinn, den defaults den Vorrang zu geben. Bei unterordnen dann wie css, sprich
/root/@meta.nml
/root/Index.nml
/root/foo/indexWird @meta sich auf beide *.index.nml anwenden. Aber bei
/root/@meta.nml
/root/Index.nml
/root/foo/index
/root/foo/@metaWird der @meta im foo ordner die Angaben im Root ordner blockieren.
"Ließe sich aneamal-config.php eventuell ganz durch eine solche Lösung ersetzen"
Vlt sollte die vorerst als wurzelstumpf bleiben, damit nerds darin sich austoben können bevor sie sich ans html oder main machen.
Spannend wird es bei @header und @meta: In ../index.nml würde ich meta tags aus bar.nml nicht übernehmen wenn bar.nml eingebunden wird, aber wohl aus @header - zb wenn man nur ein, zwei metaangaben hat, ist es ökonomischer alles in @header.
Ich würde sagen, wenn der usende später ein @meta zum @header hinzufügt und vergisst die metaangaben aus dem @header zu nehmen, dass @meta sich durchsetzt, ohne mischmasch mit kontrollieren was wo liegt und bei Redundanz ignorieren.
Das schützt auch den user vor unordnung und crash.
@5: Ja, in deinen Beispielen muss es sein, wie du schreibst.
Ich denke, man könnte in einer @meta.nml in einem Unterverzeichnis außerdem die Metadeklaration
@ meta: inherit
angeben, wenn man möchte, dass Metadaten aus einer @meta.nml in einem Überverzeichnis auch noch geladen werden. Das heißt, wenn man zum Beispiel diese Struktur hat:
/root/@meta.nml
/root/foo/@meta.nml
/root/foo/index.nmlund in /root/foo/@meta.nml steht "@meta: inherit", dann bekommt /root/foo/index.nml die Metadaten aus /root/foo/@meta.nml und mittelbar ebenfalls aus /root/@meta.nml.
Wenn hingegen in /root/foo/@meta.nml nicht "@meta: inherit" drin steht, dann bekommt /root/foo/index.nml nur die Metadaten aus /root/foo/@meta.nml.
Wenn mein Labrador 'inherit' an seiner Futterschüssel hat, erbt er dann das Futter vom Spitz? :-o
@7: Ich denke, das wird zu komplex, wenn Metaangaben automatisch aus @meta.nml, aber auch aus @header.nml übernommen werden. Ich würde das automatische Übernehmen gern auf aus @meta.nml beschränken.
Bei @header.nml ist zu bedenken, dass die Datei sichtbare Inhalte bereitstellt, und diese sichtbaren Inhalte kann man mit Metaangaben beeinflussen wollen. Also man kann zum Beispiel ein Bild mit [j]->… im Header haben, für das eine automatische Vorschau generiert wird, und dafür die Breite mit @pixels:800 vorgeben. Wenn aber aus @header.nml Metadaten automatisch in andere Dateien übernommen werden würden, würde das für alle jene Dateien bedeuten, dass dort Vorschaubilder jetzt auch 800 Pixel breit werden (wenn man nichts anderes angibt). Doch vielleicht will man das gar nicht; vielleicht sollten die 800 Pixel wirklich nur im Header gelten.
Anders gesagt, in @header.nml bräuchte es noch eine Syntax, um zu differenzieren, welche Metadaten darin nur lokal gelten sollen und welche woanders hin übernommen werden können.Bei @meta.nml hat man das Problem nicht, denn diese Datei ist nur für Metadaten. Ein Bild würde darin nie mit [j]->… eingebunden und so hat man auch keinen Grund, @pixel:800 zu setzen, es sei denn, man möchte tatsächlich, dass es in allen anderen Dateien gilt, für die jene @meta.nml zuständig ist.
> Das schützt auch den user vor unordnung und crash.
Aber nicht for Cash!
@9: Nur wenn der Spitz auf einer höheren Ebene als dein Labrador residiert.
@6: Ja, das mag vernünftig sein. Ich habe hier auf prlbr.de die Verwaltung meiner VG-Wort-Zähler über aneamal-config.php organisiert, was so nicht mit @meta.nml funktionieren würde. Ich müsste für VG-Wort wohl auf Dateieinbindungen mit [i]-> oder etwas eleganter [x]-> umstellen, was aber mehr Aufwand macht, als meine jetzige Lösung.
Andererseits gibt es Fälle, in denen @meta.nml Vorteile gegenüber den bisherigen Möglichkeiten von aneamal-config.php bringen wird. Wenn du zum Beispiel in aneamal-config.php eine Metaangabe für den Autor der Seite drin hast, weil du das ja quasi immer selbst bist und das daher nicht extra in jede .nml-Datei schreiben willst, aber dann jemand einen Gastbeitrag bei dir schreibt, dann kannst du die Autoren-Angabe aus aneamal-config.php nicht aus der Gastbeitrags-nml-Datei heraus „überschreiben“. Wenn die allgemeine Autoren-Angabe nicht in aneamal-config.php steht, sondern in @meta.nml per @author gesetzt wird, wird es hingegen kein Problem sein, sie in einer Gastbeitrag-nml-Datei mit @author zu überschreiben.
Es gibt also Fälle, in denen @meta.nml Vorteile bringt, und es gibt Fälle, in denen aneamal-config.php Vorteile bringt. Das spräche dafür, beides zu haben. Allerdings bedeutet das auch am meisten Komplexität.
Über die Jahre hat aneamal-config.php an Bedeutung verloren. Man braucht es nicht mehr für die Formelverarbeitung – da genügt heute, ein Mathemodul hochzuladen. Es ist überflüssig für einen allgemeinen Header/Footer/Seiteleiste und mit @meta.nml würde es auch überflüssig für allgemein geltende Metaangaben. Es bleibt wenig übrig, wo aneamal-config.php noch wirklich sinnvoll ist.
Zu den Herausforderungen dieses Ansinnens gehört, dass es nicht bei allen Metadaten sinnvoll ist, sie für mehrere Dokumenten automatisch zu übernehmen, zum Beispiel weil sie wie @title ausdrücklich seitenspezifisch sein sollen oder weil sie nicht in einer aufgerufenen Datei nützlich sind, sondern nur in einer darin eingebetteten. Von den von Aneamal erkannten Metadaten gehören in diese Gruppe:
@canonical, @description, @keywords, @label, @lang-…, @language-…, @next, @prev, @role, @shortlink, @title und vermutlich @charset.
Bei weiteren Metadaten wäre, da sie in Verbindung mit sowieso automatisch geladenen Dateien stehen, der Nutzen einer automatischen Übernahme auf der Metadatenschiene fraglich sowie ob ihre automatische Übernahme angesichts der dadurch entstehenden Komplexität vertretbar wäre:
@aside, @footer, @header, @look
Unter den Metadaten, bei denen eine automatische Übernahme sinnvoll wäre, gibt es solche, die aber überschrieben werden sollten, wenn in einer Datei manuell ein anderer Wert angegeben ist. Wenn beispielsweise für die automatische Übernahme "@author: Martin" hinterlegt wurde, in einem Dokument aber "@author: Simon" steht, dann sollte am Ende nur Simon als Autor jenes Dokumentes gelten. In diese Gruppe fallen:
@author, @dir, @errormore (neu in der nächsten Version), @icon, @lang, @language, @license, @me, @pixel, @pixels, @publisher, @robots, @translate, @up, @viewport und vermutlich @layout (hier bräuchte es zum Überschreiben noch einen Wert "default")
Dann gibt es noch die Metadaten, bei denen es sinnvoll ist, sie zusätzlich zu den manuell angegeben Daten zu übernehmen. Wenn beispielsweise allgemein "@script: ->foo.js" übernommen werden soll, kann es sinnvol sein, in einer Datei zusätzlich ein weiteres Skript zu laden "@script: ->bar.js", sodass dann in jener Datei foo.js und bar.js wirksam werden. Da wären:
@htmlhead (neu in der nächsten Version), @javascript, @script, @style, @stylesheet und vermutlich @class und @classes.
Metadaten aus einer automatisch zu ladenden Datei @meta.nml zu übernehmen steht nun auf der Agenda für die nächste Aneamal-Version.
Eine Angabe @meta:inherit à la @8 oder auch eine Angabe @meta:off zum abschalten automatischen Ladens in Analogie zu @header/@footer/@look würde den Verarbeitungsaufwand erhöhen. Warum, das will ich an einem Beispiel erklären. Angenommen, wir haben die Dateien:
/root/@meta.nml
/root/foo/bar.nml
/root/foo/cel.nml
/root/foo/dob.nmlIn /root/@meta.nml steht:
@lang: de
@author: Beppo Beispiel
@X: 26In /root/foo/bar.nml steht
@lang: en
This is how an example looks!Dann sollen im Allgemeinen beim Aufruf von /root/foo/bar die Metadaten aus @meta.nml übernommen werden, aber von /root/foo/bar.nml wie im Fall der Angabe @lang noch überschrieben werden können, sodass das Ergebnis genauso ist, als hätte in der aufgerufenen Datei
@lang: en
@author: Beppo Beispiel
@X: 26
This is how an example looks!gestanden. Der naheliegende Weg, um das umzusetzen, ist, zuerst die @meta.nml-Datei zu verarbeiten und dann die aufgerufene bar.nml-Datei zu verarbeiten, sodass die Daten dort die vorher automatisch eingebundenen ersetzen können.
Wenn man aber auch einen Wert @meta:off vorsieht, der das automatische Laden von Metaangaben unterbindet und /root/foo/cel.nml beispielsweise so aussieht:
@lang: de
@meta: off
Wer mag Beispiele?dann würde die Angabe @meta:off ja erst verarbeitet, nachdem /root/@meta.nml schon automatisch verarbeitet wurde, das heißt zu spät. Das spräche also dafür, zuerst die aufgerufene Datei zu verarbeiten und dann erst die automatischen Metaangaben (falls das nicht per @meta:off ausgeschlossen wurde) und dabei darauf zu achten, dass von den automatisch geladenden Metaangaben nur die verwendet werden, die nicht schon durch die aufgerufene Datei gesetzt wurden.
Letzteres wird allerdings dadurch erschwert, dass es in Aneamal auch eine Syntax gibt, um das überschreiben von Metadaten zu verhinden (und das ist auch gut so). Wenn beispielsweise /root/foo/dob.nml dies steht:
@X?: 17
Ich bin @X Jahre alt!Dann bedeutet die Angabe @X?:17 dank des Fragezeichens, dass @X nur 17 sein soll, wenn nicht schon ein anderer Wert gesetzt wurde. Diese Metadeklaration soll keine automatisch geladenen Metaangaben überschreiben, aber anonsten verwendet werden.
Wenn nun aber automatisch geladene Daten erst nach denen der aufgerufenen Datei verarbeitet werden, wie soll man dann an der Stelle @X?:17 wissen, ob der Wert 17 verwendet werden soll oder nicht?
Lösbar ist das alles, aber es würde die Komplexität erhöhen. Ich überlege daher, erst einmal keine Metadeklaration @meta zu unterstützen, mit der das automatische Laden von Metaangaben umgesteuert werden kann. Eine Entscheidung ist aber noch nicht gefallen.
Dass Metadaten aus @meta.nml automatisch geladen werden, funktioniert nun im Testbetrieb. Im Wesentlichen habe ich mich dabei an den Ausführungen in Diskussionsbeitrag @14 orientiert; @class/@classes fällt jedoch in die dritte statt in die vierte Gruppe.
Die Metadeklarationen
@meta: off
@meta: ->chosen-file.nml
können verwendet werden, um das automatische Laden zu unterbinden bzw. durch eine manuelle Wahl zu ersetzen. Auch das funktioniert im Testbetrieb. Um die Komplexität nicht zu sehr zu erhöhen – siehe Diskussionsbeitrag @16 –, habe ich im Konverter im Fall einer jener manuellen Angaben einen kleinen Geschwindigkeitsnachteil in Kauf genommen. Das automatische Laden geschieht nämlich zuerst und immer. Wird danach eine jener manuellen Angaben in der eigentlich aufgerufenen Datei gefunden, werden die bereits automatisch geladenen Werte verworfen.Eine Metadeklaration
@meta: inherit
wie in Diskussionsbetrag @8 vorgeschlagen habe ich zunächst nicht eingebaut. Erst mal schauen, wie es in der Praxis mit den neuen Möglichkeiten läuft. Das inherit-Verhalten kann dann gegebenenfalls in einer späteren Version noch immer implementiert werden, ohne Probleme bei der Rückwärtskompatibilität zu erzeugen.Die Metadeklaration
@layout: automatic
ist nun gültig – sie entspricht dem Standardverhalten, demzufolge der Aneamal-Konverter Dateien @header.nml, @footer.nml, @aside.nml und @look.css automatisch einbindet. Das Standardverhalten explizit machen zu können ist nötig, wenn in der automatisch eingebundenen Datei @meta.nml zum Beispiel allgemein @layout: manual gesetzt ist, man aber in einzelnen Dateien im Geltungsbereich von dieser @meta.nml-Datei eben doch ein automatisches Einbinden der Layout-Dateien wünscht (siehe Diskussionsbeitrag @14).Die nunmehr nahezu überflüssige Datei aneamal-config.php wird nicht mehr unterstützt werden. Sollte sich die Notwendigkeit ergeben, auch PHP-Code jenseits der [x]- und [t]-Module einzubinden, wäre zu überlegen, eine PHP-Datei nach dem gleichen Schema wie @look.css, @meta.nml et cetera einzubinden – also so etwas wie @php.php.
Gekürzt: "@layout: auto" statt "@layout: automatic"
Ich schließe diese Diskussion, da die Funktion im Wesentlichen implementiert ist. Die Idee @meta:inherit kann bei Bedarf in einer neuen Diskussion aufgegriffen werden.