ghost120

Hallo,

ich beginne gerade verschiedene Frameworks zu testen (unter anderem kohana und cakephp), da ich finde, dass sie die Arbeit doch sehr erleichtern und die ganze Anwedung viel strukturierter ist.

Nun wollte ich mal probieren ein kleines CMS zu schreiben, ich habe vor einiger Zeit schon mal ein CMS geschrieben, allerdings war das nicht wirklich OOP, also wollte ich es mal mit einem Framework versuchen.
Mein Problem liegt schon in der Planung .
Und zwar, wenn ich jetzt z.B. zwei verschiedene Arten von Seiten haben will, dynamische Seiten (Inhalte werden einfach aus der DB ausgelesen und ausgegeben) und module (z.B. ein Kontaktformular), wie löse ich das am besten?

Nach meiner Planung, würde es für das Frontend nur einen Page Controller geben, welcher die SeitenID bekommt und dann den gewünschten Inhalt aus der Datenbank holt und an den Template Controller übergibt.
Aber ist auch auch richtig so? Und was müsste ich machen, wenn nun ein Modul angefordert wird?
Ich hoffe ihr versteht was ich meine und könnt mir helfen.

Danke

lg Alex

Mister Ad

xm22

Ich sag mal so: Vergiss es für's erste. Wenn Du schon daran scheiterst, dann schau Dir doch erstmal andere CMSe an, wie die das - auf der Anwendungsebene - lösen. Dann kannst Du schauen, wie die es intern lösen.

Wie willst Du es z. B. lösen, wenn Du eine Seite hast, die Module enthalten soll? Mach Dir zuerst Gedanken, über den logischen Aufbau (u. a. Use-Case-Diagramme). Anhand derer kannst Du dann die Applikation planen. Nicht gleich drauf los arbeiten, das bringt nichts (Weiß ich aus eigener Erfahrung mit meinem CMS..).

dr.e.

Hallo Alex,

ein CMS zu schreiben ist eine weitaus komplexere Angelegenheit, als du jetzt vermuten würdest. Aus diesem Grund würde ich deinen ersten Ansatz - zunächst einfach mal eine Seite mit dynamischen Inhalten zu schreiben - vorziehen. Alleine das kann schon Komplexitäts-Grade annehmen, bei denen die Umsetzung spannend werden kann (besonders, wenn der Auftraggeber reichlich "Ideen" hat ).

Wenn du schon Frameworks ausprobierst, möchte ich auch das APF noch in den Ring werfen. Dieses bietet dir hinsichtlich dem Templating und der Gestaltung der Oberfläche deiner Webseite deutlich mehr Freiheit als das mit CakePHP und Kohana möglich ist. Bei den beiden genannten bist du immer auf eine Ebene der GUI eingeschränkt. Möchtst du z.B. in einem Template ein weiteres einbinden (z.B. besteht deine Sidebar nicht nur aus der Suche, sondern auch aus einer Anzeige von News, etc.), so bist du mit den beiden Kandidaten schon in Bereichen angelangt, wo man nicht mehr sauber MVC programmieren kann, sondern mit ViewHelpern die Frickelei beginnt. Was du letztlich verwendest, ist natürlich dir überlassen, ich weise nur in diesem frühen Stadium darauf hin, dass die Komplexität der Oberfläche den Aufwand überproportional steigern kann, wenn die Anforderungen komplexer werden.

Nun zu den Design-Fragen:
Ich persönlich würde diese beiden Arten nicht unterschiedlich handhaben. Das vergrößert deinen Code nur zu sehr. Grund: ein Kontakt-Formular wird auf deiner Seite sicher nicht alleine bestehen, sondern der Redakteuer eines CMS möchte da sicher noch ein wenig Text drum herum schreiben oder gar Bilder einfügen. Ich würde dem Redakteuer (das bist im ersten Schritt natürlich du ) einfach die Möglichkeit geben per Marker (z.B. "{{ContactForm}}") das Formular in den Inhalts-Bereich einzubauen.
Das kannst du IMHO sehr leicht realisieren, in dem du dem Controller (oder welche Komponente dafür auch immer zuständig ist) die Intelligenz gibst, solche Tags zu interpretieren und die relevanten Module dazu einbindet.
Hierzu ist natürlich ein Mechanismus zur Verarbeitung von Modulen notwendig. Mit dem APF kannst du das sehr einfach umsetzen, in dem du den dynamischen Text aus der Datenbannk nach bekannten Tags durchsuchst und diese durch den APF Page-Controller einfach als neues Kind im DOM-Baum einhängen lässt. Alternativ dazu kannst du dir eine Taglib schreiben, die den Inhalt, der im Model der Anwendung gewünscht ist, für dich automatisch aufbereitet.

Das kann man so tun, wie gesagt schränkst du dich hier auf exakt einen Controller ein. Was machst du denn z.B. wenn in der Sidebar der oben angesprochene News-Bereich auch Inhalte aus der Datenbank benötigt und dazu ein Controller verwendet werden soll?
Ich würde daher aus Design-Gründen mit einem Front- und mit einem Page-Controller arbeiten. Der Front-Controller nimmt den Request ganz am Anfang an, analysiert die URL nach den geforderten Inhalten (ID der Seite, Sprache, vielleicht noch Mapping von Keyword auf ID im SEO-URL-Fall) und schreibt diese in ein Model. Das Model dient dann dem Page-Controller dazu, die Seite auf Basis der ermittelten Informationen aufzubauen.
Im Fall eines Moduls kann das Verhalten mit dem oben aufgeführten Konzept identisch sein - es wird ja "auch nur" ein Inhalt aus der Datenbank geholt.

Solltest du weiteren Input - Prosa oder Code-Snippets - benötigen, sag Bescheid.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BattleMaster246

Ich empfehle dir ein Klassendiagramm zu erstellen. Damit kann man ein CMS und auch andere Projekte sehr gut planen. Ein Volldynamisches CMS ist für den Anfang ganz gut, aber auch das ist nicht immer so einfach. Und es dauert bis ein CMS fertig ist. Ich selbst habe für mein volldynamisches CMS 3 Monate gebraucht, natürlich habe ich nicht jeden Tag dran geschrieben.

require() oder eben mit eval() aus der DB das Kontaktformular laden.

__________________

haemoglobin

Eval wäre mir da zu gefährlich. Bisher ist mir auch noch nicht eingefallen wann man das mal nutzen sollte. Aber gut, ich bin Anfänger.

xm22

Sorry, aber die Antwort bringt ihm mal gar nichts. Was soll er damit, wenn er noch nicht mal ansatzweise ein Konzept hat?

nikosch

Was ist denn bitte ein volldynamisches CMS? 3 Monate Entwicklungszeit scheint mir recht wenig zu sein.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--