[trefixxx]

Hallo zusammen,

ich möchte eine kleine Verwaltungssoftware für meine Webinhalte schreiben - absichtlich verwende ich nicht den Begriff "CMS", weil ich damit große Systeme wie Typo3 und Joomla verbinde.
Hier geht es für mich zur Klärung der Abläufe, nicht über die Programmierung. Ich bitte euch geduldig mit mir und dem Thema umzugehen. Ich weiß, dass sich viele der hier herumtreibenden Nutzer auf einem gänzlich anderen Niveau befinden, aber bitte gebt mir die Chance, mich weiterzuentwickeln und helft mir auf die Sprünge


Also: Nun habe ich mir folgende Ideen zur Funktionsweise und zum Ablauf gemacht.

Die Software hat 2 Arten von Inhalten / Seiten:

1. Statische Seite
2. Dynamische Seite (sprich eine Blog-Seite -> letzten x Beiträge werden ausgegeben (inkl. Archiv etc., aber nachrangig))

Ebenso wie ein Templatesystem.

Folgender Ablauf (in der Theorie
In der index.php instanziiere ich die Klasse frontend (ausgelesen aus dem übergeordneten Ordner ./lib).

1. Die Klasse liest aus, welche Seite der User betrachten möchte (URL - $_GET[])
2. Nun baut sie eine Verbindung zur Datenbank auf,
3. sucht nach den vorhanden Datensätzen, die laut übergebenen Wert $_GET[] passen
4. speichert alle Informationen in einem Array
5. über die inkludierte Klasse template() wird der Platzhalter {$content} mit den wesentlichen Daten ersetzt (können natürlich auch $title o.Ä. sein)

Nach meinem Verständnis müsste nach diesem Prinzip eine solche Aplikation aufzubauen sein.
Nun aber werfen sich mir folgende Fragen auf:

• Die Übergabe habe ich "früher", als PHP-Include noch im Trend war, mit $_GET[] gelernt. "Heute" wird ja mit ModRewrite gearbeitet, sprich solche Variablen treten gar nicht mehr auf. Wie aber kann ich nun Seiten per www.domain.de/page53/ (Kann man noch ganz einfach per RegEx "page53" auslesen und php danach in der Datenbank suchen lassen?!) ausgeben?
• Wie kann ich unterscheiden zwischen statischen und dynamischen Seiten?
• Könnte ich mit diesem Prinzip auch jeder Seite ein eigenes Template zuordnen? Nach dem Motto: if($_GET['page'] == "Seite23"){ load("Seite23.tpl"); }

Mich interessiert es brennend, was ihr dazu sagt, weil ich sehr unsicher bin, wie ein solches System arbeiten - und nicht einfach nur das, sondern effizient. Im voraus also schon mal vielen Dank für eure Tipps!!!

[Basti]

Hi "trefixxx".

Klingt doch gut, was du da vorhast. Zu deinen Fragen:

modRewrite schreibt einfach einen URL um. aus example.com/pageX wird z.B. example.com?page=pageX. Du kannst in dem Fall also auch über $_GET['page'] auf diesen Wert zugreifen.

Die Unterscheidung zwischen dynamischen und statischen Seiten würde ich einfach in der Datenbank notieren und zwar würde ich einen Seitentyp oder ein Modul definieren. das eine Modul heißt "StaticContent", das andere "Blog", das nächste "ContactForm" oder so. Pro Seite kannst du dann genau dort in dieser Seiten-Tabelle ein Template angeben. Sinniger ist es aber wahrscheinlich (je nach Anforderungen), diese Templates an die Module zu binden (über eine weitere Datenbank-Tabelle zum Beispiel oder über entsprechende Namensgebung der Templates).

Basti

[trefixxx]

Zitat von Basti

[...]
Die Unterscheidung zwischen dynamischen und statischen Seiten würde ich einfach in der Datenbank notieren und zwar würde ich einen Seitentyp oder ein Modul definieren. das eine Modul heißt "StaticContent", das andere "Blog", das nächste "ContactForm" oder so. Pro Seite kannst du dann genau dort in dieser Seiten-Tabelle ein Template angeben. Sinniger ist es aber wahrscheinlich (je nach Anforderungen), diese Templates an die Module zu binden (über eine weitere Datenbank-Tabelle zum Beispiel oder über entsprechende Namensgebung der Templates).
[...]

Kannst du das vllt. etwas näher erläutern?
Du sagst also, dass in einer extra Spalte innerhalb der Seiten-Tabelle ein Seitentyp angegeben werden soll. Dieser Seitentyp, je nach Wert (z.B. StaticContent), ruft dann das dazugehörige Template auf (z.B. "static.tpl").

Ich glaube aber das meintest du nicht...

[Basti]

Zitat von trefixxx

Du sagst also, dass in einer extra Spalte innerhalb der Seiten-Tabelle ein Seitentyp angegeben werden soll. Dieser Seitentyp, je nach Wert (z.B. StaticContent), ruft dann das dazugehörige Template auf (z.B. "static.tpl").

Ich glaube aber das meintest du nicht...

Nicht ganz. Es wird kein Template eingebunden, sondern ein Controller sozusagen. Ich schreib das mal nicht-objektorientiert (wenn ich das irgendwie sinnig hinbekomme … hmmm)

PHP-Code:

<?php

error_reporting(E_ALL);
include(dirname(__FILE__) . '/../lib/undo_magic_quotes.php');
include(dirname(__FILE__) . '/../lib/mysql_connection.php');

$sPage = 'home';

if (isset($_GET['page']) && preg_match('/^[a-z]*$/D', $_GET['page'])
    $sPage = $_GET['page'];

$rResult = mysql_query("

SELECT
    `id`,
    `name`,
    `title`,
    `pagetype`

FROM
    `pages`

WHERE

    `name` = '" . mysql_real_escape_string($sPage) . "'");

if (mysql_num_rows($rResult) === 0)
    die('Page not found');

$aPageData = mysql_fetch_assoc($rResult);

$sPageType = $aPageData['pagetype'];
$sModulePath = dirname(__FILE__) . "/../modules/$sPageType.php";

if (!file_is_readable($sModulePath))
    die('Internal error');

$aTemplateVars = array();
$aTemplateVars['title'] = $aPageData['title'];

include($sModulePath);

Das eine Modul holt nun die letzten 5 News aus der Datenbank, ein anderes einen Text etc. Die jeweiligen Daten werden in das Array $aTemplateVars geschrieben. Dann gehts im Hauptskript weiter:

PHP-Code:


$sTemplatePath = dirname(__FILE__) . "/../templates/$sPageType.php";

if (!file_is_readable($sTemplatePath))
    die('Internal error');

include($sTemplatePath); 


das packst du natürlich besser in Funktionen oder gleich in Objekte, sonst hast du da schnell mal aus Versehen eine globale Variable überschrieben. Geht aber auch so erstmal.

Sinnig wäre sicher, den letzten include-Befehl in ein Haupt-Template zu setzen, denn bestimmte seitenbereiche sind ja in aller Regel immer gleich.

Dann bleibt natürlich die Frage nach der Struktur der Site. Da brauchst du in aller Regel einen Baum mit den einzelnen seiten, aus dem du dann die einzelnen Navigationselemente generierst.

Basti

[trefixxx]

Danke für deine umfassende Hilfestellung!

Dein Codeausschnitt macht ja das, was ich oben schon in meiner Liste dargestellt habe:

1. Holt sich die Seite aus der URL, die der Nutzer anschauen will (per $_GET[])
2. Prüft, ob die Seite in der Datenbank vorhanden ist. Wenn nicht -> Error

So, jetzt zum Interessanten

1. Gemäß des Pagetypes sucht er nach einem passenden Module in ./modules
2. Falls vorhanden, inkludiert er es (falls nicht -> Error)
3. Das jeweilige Module (z.B. Blog oder Static) holt sich anschließend den passenden Content aus der Datenbank und ersetzt den Templatetag dadurch

Ich hoffe ich habe deinen Code und deine Beschreibung richtig verstanden, wovon ich jetzt einfach mal ausgehe.
Deine Vorgehensweise hat, so denke ich, allerdings zwei Nachteile.

• Die Seitenformatierung ist nicht mehr NUR in der .tpl zu editieren, so wie ich es mir von vorne herein gewünscht habe, sondern das Module beeinflusst die Struktur ebenfalls (denn hier werden ja Die Content-relevanten Daten ausgegeben)
• Ich muss für jeden Seitentyp ein eigenes Modul entwerfen und habe hier wahrscheinlich doppelten Code (obwohl das, denke ich, mit interfaces zu regeln wäre)

Wie steht es damit?
Nochmals vielen Dank, dass du dir die Mühe machst!!

[Basti]

Zitat von trefixxx

• Die Seitenformatierung ist nicht mehr NUR in der .tpl zu editieren, so wie ich es mir von vorne herein gewünscht habe, sondern das Module beeinflusst die Struktur ebenfalls (denn hier werden ja Die Content-relevanten Daten ausgegeben)

Nein, die Module bzw. Controller geben nichts aus. Sie lesen nur die Daten aus der Datenbank und wählen aus, welches Template eingebunden werden soll (falls das nicht eben schon per Konvention festgelegt ist).

• Ich muss für jeden Seitentyp ein eigenes Modul entwerfen und habe hier wahrscheinlich doppelten Code (obwohl das, denke ich, mit interfaces zu regeln wäre)

In meinem CMS besteht ein Seitentyp aus beliebig kombinierbaren Modulen. Aber wenn du es einfach möchtest, dann hast du pro Seitentyp eben nur ein Modul. Redundanzen hast du da womöglich, aber ich sehe gerade nicht, was genau du meinst. Wie willst du es denn anders lösen, als jeweils ein eigenes Modul zu schreiben. Ein einfaches Text-Modul zieht sich doch die Inhalte ganz anders aus der Datenbank als ein Blog-Modul und erfordert auch andere Oberflächen und Routinen zur Eingabe und Veränderung der Inhalte.

Ein Interface musst du natürlich definieren, klar.

Basti

[trefixxx]

Zitat von Basti

[...]In meinem CMS besteht ein Seitentyp aus beliebig kombinierbaren Modulen.[...]

Die Kombination der Module besteht darin, die Aufgabenbereiche aufzuteilen, oder wie muss ich das verstehen?

Nichtsdestotrotz (hihi), ich hab die Funktionsweise verstanden und vielen Dank, du hast mir sehr geholfen!

[Basti]

Zitat von trefixxx

Die Kombination der Module besteht darin, die Aufgabenbereiche aufzuteilen, oder wie muss ich das verstehen?

Die Idee ist, durch diese Definition von Seitentypen einerseits Komplexität vor dem Benutzer zu verbergen, also eine einfach Oberfläche anbieten zu können und andererseits bestimmte Vorgaben definieren zu können.

Meine Kunden sind z.B. Dachverbände und hier kann die Verwaltung definieren: Jede Mitgliedsorganisation muss sich mit mindestens einer Seite präsentieren (was das CMS natürlich nicht umsetzen kann *g) und diese Seite enthält Überschrift, Text und ein Adressfeld mit den Kontaktdaten der Mitgliedsorganisation. Des Weiteren sind Downloads, ein Seitenbild und Unterseiten von anderen Seitentypen, wie z.B. einfache Textseite oder Bildergalerie erlaubt.

Ein Seitentyp setzt sich also zusammen aus verschiedenen Komponenten, wie Text, News, Kalender, Bildergalerie (gerade in Arbeit) und was sonst noch. Dazu wird ein Seitentyp durch bestimmte andere Vorgaben definiert: Workflows (z.B.: "Soll eine solche Seite veröffentlicht werden, muss sie zuerst von einem Redakteur freigegeben werden" (ist noch nicht implementiert)), "Wird eine Unterseite angelegt, dann wird eine neue Gruppe vom Gruppentyp "irgendwas" angelegt und die Unterseite dieser Gruppe übergeben", "Zeige bei diesem Seitentyp keine Unterseiten an" (wobei das Untermenü ohnehin noch zum eigenen Modul wird) etc.

Das Konzept ist eben, durch diese Vorgaben den Benutzer, den Autor einerseits einzuschränken, ihm aber dadurch auch eine einfache Bedienung zu ermöglichen.

Das System wird übrigens unter einer public license veröffentlicht werden. Dazu müssen aber noch Altlasten entfernt werden und Dokumentationen erarbeitet werden.

Basti

[trefixxx]

Nach Längerem wage ich mich nun daran... Habe dafür den Versuch einer Darstellung gemacht.
Ist eine derartige Umsetzung möglich?

Kann mir jemand vllt. noch mal in diesem Zusammenhand die Funktion des Moduls erklären? Erstellt es eine spezifische Query an die Datenbank oder wie?

Danke für eure Hilfe!

[Basti]

Zitat von trefixxx

Kann mir jemand vllt. noch mal in diesem Zusammenhand die Funktion des Moduls erklären? Erstellt es eine spezifische Query an die Datenbank oder wie?

Das ist doch dein Entwurf, oder? Dann solltest du es uns doch erklären können.

In „meiner Welt“ ist so ein Modul ein Paket aus einem oder mehreren Controllern oder Action-Klassen, Datenmodellen und Templates oder auch noch View-Klassen.

Ein Modul Blog könnte z.B. eine Daten-Klasse „Blog“ beinhalten, ein Daten-Klasse „BlogEntry“, einen Controller mit den Methoden list, show, add, remove, edit und vielleicht zwei Templates: list und entry (für einen einzelnen Beitrag) oder so. Das Modul wäre hier die Menge dieser Klassen und würde selbst nicht als Klasse abgebildet werden, höchstens in Form verschiedener Verzeichnisse (tempaltes/blog, dataobjects/blog config/blog etc.). Vielleicht wäre es aber auch Sinnig, Meta-Daten (Modul-Info, Version, Abhängigkeiten) und (De-)Installations-Routinen in eine eigene Modul-Klasse zu packen. Das würde vor allem dann Sinn machen, wenn es nicht einen zentralen Controller gäbe, sondern je eine Klasse für die verschiedenen Operationen (Action-Klassen, wie ModuleAction_Blog_AddEntry oder so).

Aber, wenn es einfach sein soll, würde ich tatsächlich nur eine zentrale Klasse benutzen als Controller, der für die einzelnen Operationen Methoden zur Verfügung stellt. Die haben dann im groben folgende Aufgabe:

- Prüfen, ob Anfrage Sinn ergibt und so auch gewollt war (die Werte also im Rahmen sind und nicht offensichtlich manipuliert wurden);
- Prüfen, ob der Benutzer rechte hat, die Operation auszuführen;
- Datenobjekt(e) ranholen und ggf. Manipulieren (wie, das ist Sache der Datenobjekte selbst);
- Entscheiden, welche View oder welches Template eingebunden werden soll (z.B. bei fehlerhaften Daten das Formular nochmal anzeigen, oder bei korrekter Eingabe auch einen Redirect veranlassen);
- Daten ggf. für das Template aufbereiten (hier gibt es im groben die zwei unterschiedlichen Ansätze, dass der Controller die Daten dem Template übergibt (push) oder sich das Template die Daten selbst zieht (pull));

Basti