nicht angemeldet
Hi!
Allein dafür wäre die Verwendung eines ausgewachsenen MVC-Frameworks nicht unbedingt notwendig.
Da du überlegst, ob ein MVC-Framework "unbedingt notwendig" ist: Gebe es denn irgendetwas, dass gegen einen Framework sprechen würde?
Natürlich, wenn Aufwand und Nutzen in einem ungünstigen Verhältnis stehen. So ein Framework ist zwar üblicherweise so flexibel, dass alle Teile einzeln getauscht werden können. Wenn dir der Router nicht zusagt, nimmst du einen anderen. Wenn du nur etwas Funktionalität hinzufügen willst, kannst du ein Plugin ankoppeln. Zum Beispiel diese Pluginverwaltung, die ja bei jedem Scriptaufruf zumindest ermitteln muss, ob Plugins auszuführen sind, kostet ein wenig Zeit. Und so läppert sich eins zum anderen. Für die Wartung ist das zwar alles schön strukturiert, aber auf Kosten der Performance. Du kannst am Ende nur weniger Requests bearbeiten als mit einem Geradeaus-Script ohne optionale Wenns und Abers.
Du willst jedoch unbedingt ein Framework kennenlernen - also mach das! Der Nutzen ist dann auch der Lerneffekt.
Datenbank ist wohl das beste. XML ist eher ein Austauschformat und weniger für ständige Änderungen geeignet.
Aber wäre denn folgendes sinnvoll?:
Alle Daten werden von Adminstrator in Form von XML-Dateien verwaltet, d.h. es werden Teile gelöscht, hinzugefügt und eingefügt. Danach spielt der Admin alle geänderten Daten via FTP aus den Server. Zusätzlich kopiert er noch eine Datei rüber, an der der mein System erkennen kann, dass die Datenbank aktualisiert werden muss. Beim nächsten Aufruf meiner Seite erfolgt die besagte Datenbankaktualisierung, d.h. alle Informationen aus den XML-Dateien werden nun in die Datenbank eingetragen. Alle weiteren Zugriffe auf die Informationen erfolgen via Datenbank bzw. die XML-Dateien werden am dann nicht mehr beachtet.
Denkbar ist das. Wie genau stellst du dir die Datenbankaktualisierung vor? Du brauchst dazu Insert- und Update-Elemente in deiner XML. Und um diese aus deinem lokalen Datenbestand zu ermitteln, benötigst du eine Kennzeichnung der Änderungen, die du beim Erstellen der XML-Datei zurücksetzen musst. Das ist aufwendig und mit einem Dump wesentlich einfacher zu regeln, wenn du in beiden Systemen immer die gleichen Daten hast (sogar für einzelnen Tabellen, wenn du nicht gerade referenzeielle Integrität vom DBMS überwachen lässt). Du wirst im CMS ja nicht gerade mehr als eine Handvoll MB verwalten.
Die Aktualisierung sollte der Administrator einspielen, denn sonst hast du bei jedem Scriptaufruf eine Prüfung auf zu erledigende Änderungen. Das kostet und wenn was schief lief, bekommt es keiner mit, bis sich ein Besucher beschweren kommt.
[Bei HTML im Content] ist besondere Aufmerksamkeit auch seitens des Bearbeiters gefragt, denn es darf durch seine selbst eingefügten Code-Teile zu keinem Syntaxfehler kommen. [...] Wenn er jedoch irgendwo ein Element offen lässt, dem ein Platzhalter folgt, ist man mit den einzufügenden Daten bereits im Anweisungsmodus und kann auch ohne HTML-eigenen Zeichen zu verwenden, die ja maskiert werden würden, in gewissen Grenzen Code einfügen.
Das mit dem offenen Element in Kombination mit einem "Platzhalter" verstehen ich nicht vollständig. Nur um ein mögliches Verständnisproblem aus dem Weg zu räumen: Ich verwende keine klassischen Platzhalter im Sinne von<div><!--{{TEXT.LINKLISTE}}--></div>oder Smarty(artiges), sondern normalen - eben für die Darstellung bestimmten - PHP-Code, wie von Kohana vorgesehen.
Dann ist immer noch HTML/CSS/JS-Injection möglich, egal ob da PHP-Code die Daten einfügt oder Platzhalter ersetzt werden. Beispiel: Der Admin vergisst ein <div class="foo" zu schließen, und danach sollen Daten eingefügt werden. Dann können Daten, die aussehen wie attribut=wert, im Code-Teil statt im <div class="foo">Inhaltsbereich</div> landen. HTML-eigene Zeichen <>&" würden durch dein htmlspecialchars() behandelt. Wenn du vergisst, dabei ENT_QUOTES zu setzen, stehen dem Ausnutzer wenigstens noch die '' zur Verfügung und er kann Attributwerte besser abgrenzen.
Würdest du hier den Lebenslauf als eigenes "Inhaltselement" sehen oder würdest du es in eine Mitarbeiterseite eingliedern? Ich gehe davon aus, dass du die ganze Mitarbeiter-Seite zur "Datenhaltung" zählen würdest.
Definiere "ganze Seite". Du meinst sicher den Teil ohne das allgemeine Gerüst oder kann jeder Mitarbeiter komplett eigengestaltete Seiten haben?
Allerdings werden ja vieler solcher Texte wie Lebenslauf und Publikationsangaben-Auflistungen häufig editiert - andere HTML-formatierte Texte wie Unternehmensprofil wieder weniger.
Die Häufigkeit ist nicht das Kriterium sondern eher wer es sinnvollerweise machen kann/soll - technisches Personal oder Mitarbeiter der fachlichen Abteilungen.
In beiden Fällen der "fachliche Mitarbeiter".
Ja, aber im Gegensatz dazu wird das Seitengerüst wohl eher vom technischen Personal betreut. Das ist dann Template-Datei und kein Content wie die obigen Beispiel.
Lo!