[Berti]

Hallo ich will mir ein eigenes CMS erstellen. Leider habe ich noch keinen Plan, wie ich das anstellen will. Ich brauche ja irgendwie ersteeinmal eine Struktur für das ganze. Dann müsste ich wissen, wo man anfangen soll. Gibt es also eine Art Anleitung für das Erstellen eines CMS, aber nicht mit Codes, sondern wie man anfangen soll.

[WarrenFaith]

Das Tutorial bezieht sich zwar auf ein Browsergame, aber das was vermittelt werden soll ist das gleiche: Erstellung eines Projektkonzepts
Wichtig ist halt erstmal festzuhalten, was dein CMS können soll. Dann überlegst du dir mit welcher Technik (PHP, ASP ....) du das realisieren willst. Danach würde ich persönlich anfangen, eine Konfigurationsklasse zu schreiben, die Konfigurationen via File/DB lesen kann. Wenn du die später machst, musst du eventuell vieles umschreiben. Und dann würde ich ne Startseite kreieren und Stück für Stück Login, Anmeldung, Userbereich, Kalender und und und...

[Ben]

Nunja, ein CMS ist ja nichts anderes, als ein System zur Erstellung und Manipulation von Datenbeständen.

Heißt also, dass du generell "nur" Daten schreibst, liest, änderst, löschst.
Und genau das solltest du zu Beginn machen. Kleinere Funktionspakete oder Klassen schreiben, die du dann für genau das einsetzen kannst.

Die von WarrenFaith angesprochene Konfigurationsklasse braucht zu Beginn eigentlich nichts, sondern sollte einfach Konfigurationsdaten zur Verfügung stellen.

Simpelstes Beispiel:
Du schreibst eine Datei config.ini, liest diese mittels parse_ini_file ein und greifst via get-Methoden (oder via __get()) auf die Daten zu.

Das ist wenig Aufwand und mehr brauchst du auch erstmal nicht.

Danach schreibst du wie gesagt kleinere Pakete, die du dann als "Framework" nutzen kannst, heißt also, dass du im Endeffekt etwas haben solltest, was dir den schnellen Zugriff auf das Dateisystem und die Datenbank bietet.

Wenn du das hast (natürlich gibt es noch 'ne Menge anderer Sachen wie Datenfilterung, Auswertung des URLs oder oder oder oder ...), ist alles, was danach kommt eigentlich nur das Zusammensetzen von Puzzleteilen.

Grüße, Ben.

Wenn Du ein CMS erstellen willst, must Du erst einmal ein Backend erstellen.
Du fängst mit einem Loggin-System an.
Wenn Das steht, kommt die Benutzerverwaltung...z.B. eine Gruppeneinteilung in Administrator, Autor und User.
Dann kommen Module, die Du sonst noch für die Administratorgruppe haben willst, z.B. Statistiken, Verwaltung von Mediadateien.
Dann kannst Du Dich dem Authorenbereich widmen. Erstellen und verwalten von Kategorien, erstellen und Ändern von Inhalten.

........und was Du noch so alles haben willst.

[Basti]

Geil, lauter verschiedene Ansätze.

Hier noch einer: *g

Ich finde es wichtig, dir erstmal den prinzipiellen Ablauf anzuschauen, wie Anfragen an Webanwendungen abgearbeitet werden. In Kurzform:

1. Dinge tun, die für alle Anfragen nötig sind;
2. Festlegen, wer die Anfrage bearbeiten soll;
3. Anfrage bearbeiten und entscheiden, was der Benutzer zu Gesicht bekommen soll;
4. Inhalte dann ausspucken;

Etwas konkreter:

1. Alle Anfragen gehen an einer zentralen Stelle ein. Das macht Sinn, weil, bis auf wenige Ausnahmen, für die der Overhead dann aber tragbar ist, jede Anfrage bestimmte Teile des Systems einfach braucht. Die üblichen Kandidaten sind hier Konfiguration, Error-Handling, Logger, Request-Objekt, Session, Datenanbindung, Template-Engine, i18n (...) und natürlich die ganze "Infrastruktur" des Systems.

2. Dann macht es natürlich keinen Sinn, wenn ein FrontController alle Funktionen des Systems kennt, also alle Funktionen, die du in deinen Anforderungen definierst, denn du müsstest ihn ja bei jeder Änderung mitverändern. Typisches Negativ-Beispiel sind hier die switch-Konstrukte, in denen bestimmten Request-Parametern PHP-Skripte fest zugeordnet werden.

Schon in den Anforderungen wirst du die Funktionen ja in bestimmte Bereiche gliedern (Benutzer: Profil/hinzufügen/auflisten/registrieren/.. Seite ansehen/änden/löschen/veschieben/..). Eine solche Gruppierung würde ich dann auch in das System übernehmen (bzw. ich mach das eben so), so dass es dann eben Module/Komponenten zur Benutzerverwaltung und zur Seitenverwaltung (...) gibt. Die kannst du dann einbinden und eben die entsprechende Methode aufrufen.

3. Die Methode weiß dann, was zu tun ist. Sie guckt z.B. ob der Benutzer die entsprechenden Rechte hat, ob die Anfrage Sinn macht, ob die Daten vollständig sind und führt dann ggf. Datenmanipulationen aus oder generiert eine Fehlermeldung bei invaliden Formulardaten oder tut eben auch erstmal nichts dergleichen (oder bindet ihrerseits Module ein). Im Ende entscheidet diese Methode aber immer, wie es weiter gehen soll. Hier gibt es in der Regel die Optionen: Binde die Sicht XY ein, übergib an eine andere Funktion, leite zur Anfrage sowieso weiter, Zeige nichts an, ...

Da das eben immer etwa so abläuft, kannst du da eine Menge abstrahieen. Auch ganz gut sich klar zu machen, dass es in der Regel vor allem die Methoden auflisten, anzeigen, bearbeiten, einfügen und löschen sind, mit denen man es so zu tun hat. Und auch, dass eben der Hauptkrempel Formulargeschichten sind, die immer nach dem Schema Formular ausspucken - Werte prüfen - falls nicht korrekt, Formular nochmal mit Fehermeldung ausspucken - falls korrekt, Daten speichern und einen Redirekt auf ... wohin auch immer machen.

In jedem Fall ist es gut, diese einzelnen Methoden kompakt und übersichtlich zu halten und möglichst unabhängig, so dass du dort einfach was ändern kannst, wenn sich die Anforderungen ändern.

4. Dann den Mist eben ausspucken. Dazu gibt es dann auch viele Vorgehensweisen. Interessant, sich vielleicht mal über die beiden Prinzipien "push und pull" von Template-Engines auseinanderzusetzen. Also, ob die Templates mit Inhalen gefüttert werden, oder ob sie sich diese selber ziehen.

Das ist natürlich nur ein Modell (oder ein grober Plan für viele Modelle). Ich hab diese Aufgliederung in meiner ersten etwas größeren Anwednung schon gut umgesetzt bekommen, als ich noch keinen Plan von OOP, MVC etc. hatte, indem ich für jede "Action" eine Datei angelegt hab, die alle auszugebenden Daten in ein überall gleich benanntes Array geschrieben hat und dann die einzubindende Seite (in der dann Header und Footer includet wurden *g) einfach eingebunden hat.

Hat sich bei mir in jedem Fall bewährt und auf dieser Schiene anzufangen, also erstmal den grundegenden Ablauf irgendwie sinnig abzubilden (so, wie es mir da eben möglich war - und heute ist das ja auch nichts anderes). Eigentlich sowas, wie einfach drauflosschreiben und bei jeder Wiederholung anhalten und sich fragen, ob das sein muß, ob man da nicht was ausklammern kann.

Auch wichtig oder hilfreich finde ich es, immer von dem Blickwinkel der Bedienung die Dinge zu betrachten. Also auf der einen Seite z.B. die Stuktur für Module so zu gestalten, dass sich diese möglichst einfach und schlüssig progammieren lassen (sich das System also mit einem Modul optimal bedienen lässt), ebenso die Templates, aber natürlich auch, wie die verschiedenen Benutzer das System hinterher bedienen wollen/sollten. Hier auch nicht schlecht, deren Anliegen und Wunsch-Vorgehenswesen einfach mal festzuhalten und die Wünsche zu gewichten.

Ich zum Beispiel hab keinen Bock, mich erst in ein Backend einzuloggen um eine Seite einzugeben und die dann womöglich noch in einem völlig getrennten zweiten Schritt in verschiedene Navigationsbäume einzuhängen. Ich will sowas auch nicht meinen Kunden verkaufen. Ich will mich durch die Seite klicken und an Ort und Stelle neue Inhalte hinzufügen - passt aber auch dann natürlich wiederum nicht auf alle Anforderungen.

Dazu noch was, das in gewiser Weise gegen meine Worte oben spricht (aber nicht wirklich Bleib absolut bei deinen Anforderungen und mach dir erstmal keinen Kopf, was noch alles gebraucht werden könnte. Andernfalls wächst dir das schnell über den Kopf, weil das einfach extrem komplex ist. Letztlich stehen sich immer Flexibilität und Bedienkomfort (aber natürlich auch Kosten und Zeit) gegenüber. Klar ist es ärgerlich, alles umbauen zu müsen, wenn man mal wieder in einer Sackgasse ist, weil man etwas vorher nicht bedacht hat (deshalb ja auch deine Frage und unsere Antworten). Aber es geht ja nicht anders. Die Komplexität erschließt sich einem erst nach und nach und vieles kann man im Vorfeld noch nicht absehen (wenn man für sich selber Neuland betritt). Hier dann noch alle Eventualitäten draufzupacken ist kontraproduktiv und geht eben nicht nur auf die Gehirnwindungen und auf die Produktivität, sondern auch auf die Bedienbarkeit. Und darum geht es ja letztlich: Die Ziele (Inhalte zu präsentieren etc.) möglichst einfach umsetzbar zu machen.

Basti

[Ben]

Ist eigentlich im Groben auch mein Ansatz Basti .. aber du hattest einfach mal wieder mehr Lust zu schreiben ... hehe

[Berti]

Danke für die vielen Antworten, die waren z.t wirklich sehr hilfreich. Ich hab' hier noch einen Artikel über OOP (Opbjekt-Orientierte-Programmierung) gefunden. Ist auch sehr hilfreich.
http://tut.php-q.net/klassen.html

[Basti]

...der bezieht sich noch auf PHP 4, daher hier mal noch eine Ergänzung:

http://php.net/manual/en/language.oop5.php


Basti