nicht angemeldet
moin,
Oberste Prämisse ist die Datenreinheit. Es dürfen also in den Daten selbst (bis auf wenige Ausnahmen wie span, oder br im Fliesstext keine HTML-Elemente oder Attribute in den Daten vorliegen. Diese Daten werden als serialisierte Arrays oder als JSON in der DB gespeichert.
Serialisiert ja, JSON nein, Letzteres ist zwar für die eigene bildliche Vorstellung einer Datenhaltung und ~Strukturierung hilfreich, praktisch jedoch viel zu langsam. Diese Frage stellt sich umso mehr, je feiner Du die Abstraktion einer Seite machst, also die Zerlegung in Komponenten.
Du kannst an die Performance Zugeständnisse machen, wenn der Content geschrieben wird (Management), nicht jedoch bei der Auslieferung (User Request). Insofern spricht überhaupt nichts dagegen, wenn in der Datenhaltung eine Seite bereits zum Teil zusammengebaut vorliegt, z.B. in Teilen als Head, Body und Footer. Konkreter Fall: Ein Body beeinhaltet eine Tabelle oder eine verschachtelte <ul>, o.a. Inhalte, die mit einem aufwändigen Serverprozess erzeugt werden. Solche Prozesse sind im Management besser aufgehoben.
In meiner Praxis abstrahiere ich in Sachen Trennung nur die Attribute vom Body. Attribute im Sinne eines CMS sind z.b. title, meta-descr, author, last-modified usw. In Perl sieht eine Datenstruktur dann so aus:
$obj = {
title => text/plain,
author => text/plain,
body => text/html,
};
D.h., Du hast in einem Objekt mehrere Content-Types, jedoch alles immerhin noch Text. Wenn Du das noch weiter abstrahieren willst, bekommst Du auch image/gif u.a. und da wirds mit der Datenhaltung schwierig ;-)
Und selbstverständlich kann eine Seite auch schon fix und fertig zusammengebaut auf dem Server liegen, z.b. als "datei.html".
Hotti