[kampfgnom]

Hi,
angeregt durch diesen thread hab ich mir auch einmal gedanken über mein System gemacht.

Folgendes habe ich mir bisher überlegt:
Ich habe verschiedene Module (Blog, News, was-weiß-ich). Jedes dieser Module kann flexibel auf seiten eingebunden werden.

Ich habe ein Backend in dem das alles verwaltet wird. Meine Überlegung ging in zwei richtungen:
zum einen, bekommt jedes Modul verschiedene Administrationsmethoden.
Dadurch hab ich nur eine Klasse pro Modul.

Oder ich trenne das ganze in zwei schichten:
In die Back und in die FrontEnd schicht. Das ganze wird dann durch konfigurationsdateien miteinander verbunden...

Ich selbst tendiere ja zum ersten. Wollte aber vorher gerne die Meinung von euch hören. Vielleicht renn ich auch voll gegen einen Baum und das is völliger Mist

[dr.e.]

Hallo,

um dir "Kosten" bei der Erstellung der Software zu sparen, solltest du so viele Gemeinsamkeiten zwischen Frontend und Backend machen. Im Grunde gibt es ja auch einige Themen, die in beiden Bereichen vorkommen. Somit kannst du zu Mindest große Teile der Daten- und Business-Schicht für beide verwenden. Die GUI wird sicher in einigen Punkten different sein, jedoch auch dort ist es sicher möglich gleiche Bereiche auszumachen und als generische Komponente zur Verfügung zu stellen.

[kampfgnom]

jupp, so hatte ich mir das auch vorgestellt.

[dr.e.]

OK, dann geht es ja nur noch um die Details. Falls du dazu einen Rat haben möchtest, melde dich einfach.

Wichtig ist nur, dass du eine gute Schnittstelle für die Einbindung deiner Module schaffst, sprich dass diese alle Informationen des Rahmens mitgeteilt bekommen und damit sauber agieren können (Stichwort: Sprache).

[kampfgnom]

Zitat von dr.e.

Wichtig ist nur, dass du eine gute Schnittstelle für die Einbindung deiner Module schaffst, sprich dass diese alle Informationen des Rahmens mitgeteilt bekommen und damit sauber agieren können (Stichwort: Sprache).

Genau darüber grübel ich gerade.

Sollte ich ein interface erstellen welches in etwa so aussieht:

PHP-Code:

interface module
{
 public function administration()
{
}
public function execute()
{
}

} 


so richtig weiß ichs auch noch nicht...

[dr.e.]

Hallo Gabriel,

ich hab den Satz hingeschrieben, weil ich schon vermutete, dass du ein Konstrukt der Art im Kopf hast. Habe ich zumindest aus deinen Zeilen gelesen...

Eine Verquickung der Art macht aber IMHO keinen Sinn. Vielmehr solltest du darauf achten, dass du die Elemente noch mehr granulierst und nicht einen großen Hammer "Administration" und "Ausgabe" hast. Diesen beiden Bereichen ist mehr gemeinsam, als man mit diesen beiden Methoden "gemeinsam machen" könnte. Grundsätzlich gilt es daher sich zu überlegen, welche Funktion dein Modul haben muss. Sofern es abgeschlossen und unabhängig von anderen Bereichen ist, fällt das auch nicht schwer. Geht man davon aus, dass das Modul im 3-Schicht-Modell entworfen werden soll, so kann man schon mal eine gemeinsame Daten- und Business-Schicht erzeugen, da sowohl Frontend als auch Backend die selben Objekte verwenden / anzeigen / löschen / ... / whatever. Es muss also innerhalb der Datenschicht - beginnen wir mit dieser - also immer die Möglichkeit geben, die relevanten Objekte zu lesen, zu speichern und zu löschen. Weiterhin - im Fall von mehreren Business-Objekten - müssen Beziehungen auf und wieder abgebaut werden können. All diese Methoden sind beiden Bereichen gemein. Auch in der Business-Schicht finden sich Funktionen wie Paging, View-Weiterleitung, usw. wieder, die man in eine gemeinsame Business-Komponente aufnehmen kann.

Nun kommt die Präsentationsschicht und diese unterscheidet sich tatsächlich, denn hier habe ich zwei unterschiedliche Views, die wiederum unterschiedliche Subviews besitzen können. Um zu erörtern, welche Views man überhaupt haben wird, ist es nicht verkehrt, sich Screens zu machen und den Prozess mal durchzuspielen. Nehmen wir an, du möchtest News verwalten. Die Ausgabe der News ist dabei trivial: eine blätterbare Liste. Das Backend hingegen wird eine Möglichkeit haben Kategorien zu pflegen, News anzulegen, zu löschen usw. Ausserdem wird man auch eine Login-MAske zum Backen haben, damit nicht jeder im Backend Blödsinn treiben kann. Letzteres setze ich nun einfach vorraus.

Ziel in der Pres-Schicht ist es also eine Möglichkeit zu schaffen, Views zu definieren und diese in den allgemeinen Backen-Rahmen (siehe Login, ...) einzubinden. Meine Erfahrung lehrt mich, dass man hier einen ganzheitlichen Ansatz wählen muss um diese Integration schaffen zu können. Das bedeutet, dass man nicht einfach irgendein Modul per require() und vorgelagertem if() einbinden sollte, sondern dass eine Applikation ein komplettes Modell besitzt. Ich habe hier bewusst den Begriff "Modell" gebraucht, da ein Modul einige Informationen mitgegeben bekommen muss, damit es lauffähig sein kann.

Aus der beschriebenen Erfahrung ist die heutige Implementierung des PageControllers des Adventure PHP Frameworks entstanden. Dieser bietet genau die Möglichkeit, Module an beliebiger Stelle einzuhängen. Ich bediene mich dabei des MVC-Pattern mit einigen Erweiterungen. Das bedeutet, dass ich eine GUI komplett abstrahiere und jeder Knoten des DOM-Baums kann ein MVC-Knoten mit einer View-Definition (Template), einem Controller und einem Model (meist das Model der Anwendung) sein. So habe ich die Möglichkeit im Inhaltsbereich der Admin-GUI einfach ein Modul einzuklinken, das genau nach dem beschriebenen Muster implementiert ist. Durch die einzelnen Templates definiere ich die Views des Backend-Moduls "News" - sprich das Menü, die Möglichkeit Kategorien und News zu verwalten und klinke diese per Tag in den "Rahmen" ein. Die Business- und Daten-Schicht werden dann von den entsprechenden Contollern der Views benutzt. Beispiel: Zeige ich den View zur Bearbeitung des Views an, wird im ersten Schritt vom Controller die Liste der verfügbaren Kategorien ausgegeben. Diese holt sich der Controller von der Business-Komponente, die wiederum von der Datenschicht. Letztere bedient sich dabei nochmal einer MySQL-Klasse zur Abstraktion der Datenschicht. Das Formular ist dabei so gestaltet, dass es auf den Folge-View verweist. Auf diesem wird dann das Formular zur Bearbeitung der Kategorie angezeit, ...

Was ich damit sagen will ist folgendes: ich würde keine große Klasse entwerfen, die zwei Methoden kennt, sondern auf der GUI granularer werden. Monolite baut heute eigentlich keiner mehr!
Das erleichtert spätere Änderungen und macht den Code übersichtlicher. Mit Frameworks wie dem Zend Framework (dein Code-Snippet sieht mir ganz danach aus) hast du die Möglichkeit, das in Actions zu gliedern. Hier kann man jedoch auch jeden View aufgliedern um den Prozess einfacher zu gestalten. Einfacher sowohl in der Implementierung, als auch in der Strukturierung.

Falls du Interesse hast, kannst du dir mal das Kommentar-Funktion-Tutorial unter http://adventure-php-framework.org/S...ktion-Tutorial ansehen. Dort habe ich versucht zu zeigen, wie man unterschiedliche Pattern für sich nutzen kann und wie das Modul einfach per Tag in die entsprechende Umgebung eingesetzt werden kann. Das Modul ist zwar keine News-Verwaltung, zeigt aber - denke ich ganz gut - wie man modulare GUI-Elemente erstellen und einbinden kann.

[kampfgnom]

Vielen Dank dr.e!!

Zitat von dr.e

ich hab den Satz hingeschrieben, weil ich schon vermutete, dass du ein Konstrukt der Art im Kopf hast. Habe ich zumindest aus deinen Zeilen gelesen...

Und du hattest vollkommen recht.

Nun gut, das ich das ganze nicht mit zwei methoden lösen kann, war mir irgendwie klar. Aber hatt dann sowas wie edit, delete, new im kopf...
Nur scheinst du, als weg zu empfehlen, das man modlue in mehrere klassen aufteilt die jeweils bestimmte aufgaben erfüllen. Also jedes Modul ist eine fast eigene Applikation( fast, weil jedes modul ja noch ein paar info's bekommen muss um zu laufen und auch nie ein vollständiges View erzeugen würde).
Verstehe ich das richtig?

Da kommt bei mir nur die Frage, wie ich das ganze dann am ende im Backend vereine.

Wie du schriebst, kann man das dann nicht mehr per if() und include machen^^

Dort liegt bisher mein größtes Problem...

Zitat von dr.e

Falls du Interesse hast, kannst du dir mal das Kommentar-Funktion-Tutorial unter http://adventure-php-framework.org/S...ktion-Tutorial ansehen. Dort habe ich versucht zu zeigen, wie man unterschiedliche Pattern für sich nutzen kann und wie das Modul einfach per Tag in die entsprechende Umgebung eingesetzt werden kann. Das Modul ist zwar keine News-Verwaltung, zeigt aber - denke ich ganz gut - wie man modulare GUI-Elemente erstellen und einbinden kann.

Das werd ich mir auf ejden fall mal ansehen! Ich denke das wird evtl. auch lösungshinweise zu meinem Problem zeigen.(zumindest klingt es so....)

Also erstmal vielen Dank an dich dr.e!!!

Ich hab erstmal lesestoff

[dr.e.]

Nur scheinst du, als weg zu empfehlen, das man modlue in mehrere klassen aufteilt die jeweils bestimmte aufgaben erfüllen. Also jedes Modul ist eine fast eigene Applikation( fast, weil jedes modul ja noch ein paar info's bekommen muss um zu laufen und auch nie ein vollständiges View erzeugen würde).
Verstehe ich das richtig?

Ja, das siehst du richtig. Ich gehe hier den Weg, jeweils eigenständige Views auf Basis von allen Views gemeinsamen Business- und Datenschicht zu erstellen.

Das werd ich mir auf ejden fall mal ansehen! Ich denke das wird evtl. auch lösungshinweise zu meinem Problem zeigen.(zumindest klingt es so....)

Die eigentliche Lösung des Problems ist die Implementierung des PageControllers, der eine solche Umgebung zur Verfügung stellt. Dazu kannst du dir vielleicht auch das Tutorial http://adventure-php-framework.org/S...eite-erstellen ansehen. Am Ende (Kapitel 4) wird beschrieben, wie man dynamisch Inhalte in die Beispielwebseite einbauen kann. Diesen Mechanismus kann man aber genauso nutzen um Backend-Module einzuklinken. Wenn du mit dem Lesen fertig bist, kann ich dir auf Basis der Beispielwebseite oder des demopacks mal ein proof of concept implementieren, damit du siehst, wie das konkret funktioniert. Wenn du Zeit und Lust hast, können wir das ganze auch in einer Skype-Session machen. Meld dich einfach!

Also erstmal vielen Dank an dich dr.e!!!

Immer wieder gerne!