Mano

Als Beispiel: Ich hatte gedacht mir eine Klasse, nennen wir sie mal "Layout", für die HTML-Ausgabe zu schreiben. Diese Klasse besitzt beispielsweise die Funktionen setTitle, setMetaTag usw... und bindet mein zuvor abgelegtes Template ein. Über den jeweiligen Controller könnte man nun noch steuern ob dieses wirklich genutzt werden soll. Darüberhinaus könnte man das Layout doch auch noch für die Ausgabe von Ajax auswechseln... oder wie sollte man dieses angehen? Wo und wie sollte ich das Layout einbinden, sodass ich für die Zukunft sehr flexibel bleibe?

Ich denke, dass ich bis dahin schon etwas weiter bin wie jetzt. Komme aber ggf. gerne darauf zurück.

Beim Programmieren hat sich bei mir vorhin folgende Frage gestellt:

Ein Modul kann selbstverständlich aus mehreren Datenbanktabellen bestehen. Bisher habe ich das immer so gehandhabt für die Tabellennamen in einer Konfigurationsdatei Konstanten zu erstellen um diese im Verlauf ändern zu können. Sollte man eine solche Datei die zur Konfiguration der Module genuzt beim Aufruf des ModulControllers einbinden oder schon eher?

Ähnliches betrifft zukünftig die verschiedenen Sprachen, wie handhabt ihr das?

__________________
www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

Mister Ad

dr.e.

Hallo Mano,

Das Geheimnis ist hier das Composite Pattern und eine hierarchische MVC-Umsetzung, die nicht Anwendungs-bezogen sondern generisch abgefasst wird. Das bedeutet, dass jeder Knoten einer Baum-Struktur nun der Root-Knoten sein kann oder auch nicht. Sofern du das jetzt schon konkret abfasst und einen Knoten als explizit gekennzeichneten Root-Knoten (Haupt-Knoten des Layouts) ausführst wird das zukünftig nicht flexibel genug sein.

Wenn du mein Code-Beispiel mal rekapitulierst, sind alle Elemente "einfach nur" ein Document im Baum, den der Page-Controller verwaltet. Nicht mehr und nicht weniger. Würde ich einen Knoten als Layout-Knoten abfassen hätte ich nicht die Flexibilität beliebig komplexe Strukturen aufzubauen, da ich beispielsweise immer einen Bezug von Knoten zu Layout brauche (z.B. Linker Bereich im Layout). Setzte ich das generisch um (im Beispiel durch ein View-Model abstrahiert), so kann alles das Layout einer weiteren Verästelung des Baumes sein oder eben nicht.

Warum nutzt du nicht verschiedene Datenbanken für die verschiedenen Module? So kommen sich diese hinsichtlich der Benamung nicht in die Quere. Präfixe sind doch "nur" ein Workaround für "nicht genug Datenbanken beim Hoster verfügbar".

Das kommt auf den Anwendungsfall an. Die Tabellen, die zur Konfiguration der Module und zur Ausführung der FC-relevanten Komponenten angeht muss das ja schon vor dem Controller/der Action des Moduls passieren. Wobei "einbinden" hier das Auslesen und interpretieren der Informationen zur Ausführung des Modules/der Module bedeutet.

Die Sprache sollte eine Modell-Information sein, die jedem Baum-Knoten und jedem Service zur Verfügung steht. Damit schaffst du eine Basis um auf jedem Knoten/Element die Sprache als Information zu nutzen oder diese gemäß den Vorgaben der Applikations-Logik zu manipulieren.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mano

Ich denke, dass es momentan noch absolut nicht bis ins kleinste Detail flexibel sein muss. Dieses wäre zwar super schön, aber derzeit mehr als unbedingt zwingend notwendig. Ich werde mir zu diesem Punkt noch einige Beispiele anschauen und hierzu eine Maßgeschneiderte Lösung für meinen Anwendungsfall entwerfen. Das was ich hier unter Beachtung eines MCV umsetzen möchte, ist schon etwas überdimensioniert Das könnte mir ein Kunde schon garnicht bezahlen... sooo viele Arbeitsstunden...

Von meinem Server hat sollte das keine Probleme geben, den soviele Datenbanken wie ich anlegen könnte, würde ich im Leben nicht nutzen können. Ich bleibe definitiv bei einer Datenbank

Also müsste dieses schon während der Dispatch im FrontController stadtfinden?

__________________
www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

dr.e.

Das muss ich jetzt nicht kommentieren, oder? (Wer wollte keine fertige und erprobte Lösung einsetzen? ) An sich hatte ich dir mit meinem Beispiel schon 10 Tage Diskussion hier erspart, aber gut.

Nein, der Front-Controller sollte transparent sein. Dein Applikations-eigener "Dispatch-Vorgang" muss in einer Action passieren, die beim FC registriert ist. Nur dann kannst du den FC auch für andere Projekte nutzen.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mano

Wenn man es genau nimmt, könnte ich auch eine beliebige Software zur Vereinsverwaltung nehmen die auf dem Markt existiert. Dadurch wäre die gesamte Programmierung überflüssig und der Lerneffekt gleich null

Für mich ist dieses ein Projekt, welches es mir ohne eine genaue Zeitvorgabe erlaubt meine eigenen Ideen und Vorstellungen so umzusetzen wie ich das gerne hätte. Da ich eine solche Freiheit in unserer Agentur nicht habe, bin ich über die Entwicklung hier sehr froh

Wie gesagt, ich bin wirklich dankbar über eure Tipps und melde mich während der Zeit bestimmt nochmal

__________________
www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

Mano

Hallo,
ich bin mit meiner Entwicklung nun noch einen weiteren Schritt in dieser Woche voran gekommen und habe heute begonnen meine bisherige Session-Klasse zu überarbeiten. Ich hatte mir übrelegt, die neue Session-Klasse weiterhin als Singleton-Instanz aufrufbar zu machen, da ich nicht jede Methode neu als Static deklarieren möchte.

Im bisherigen Projekt nutzte ich bereits eine Klasse für die Authentifikation der Benutzer. Diese enthält allerdings noch die Funktionen für "user_login(user, pw)" und "user_logout" die in dem neuen Schema jedoch überflüssig werden, da diese Methoden im Login-Modul im entsprechenden Model genutzt werden können.

Bei zwei Funktionen bin ich mir allerdings nicht nicht sicher:

1) Bisher wird bei jedem Seitenaufruf eine Funktion der User-Klasse aufgrufen die eine Datenbankabfrage durchführt und aktuelle Informationen in der Benutzertabelle speichert. Sollte ich dieses weiterhin hier belassen oder auslagern, wenn ja wohin?

2) Außerdem war in der bisherigen Klasse eine Funktion integriert die nach dem Login ein komplexe Logik an Benutzerrechten zusammenbaut und diese in einem Session-Array speichert. Grundsätzliche könnte ich diese Funktion auch im Login-Modul unterbringen. Mich würde allerdings interessieren, wie ihr in solchen Fällen damit umgeht?

__________________
www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

dr.e.

FC-Action des Login-Moduls. Das ist eine globale Angelegenheit, die per Facade oder Proxy für alle Module zugreifbar sein sollte.

Berechtigungen sind eine Eigenschaft des Benutzers. Ich sollte - wie oben angedeutet - in einem beliebigen anderen Modul sowas wie

aufrufen können. Dabei sollte der User als zentrales Model verfügbar sein (z.B. als UserFacade, die du singleton beziehen kannst).

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mano

Soweit so gut. Würdest Du grundsätzlich Rechte für Benutzer nicht direkt in einer Session speichern? Dann würde ich mir ggf. eine Funktion in der User-Klasse sparen ....

__________________
www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

dr.e.

Nein, denn direkt in der Session ist hinsichtlich der Kapselung unsauber.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mano

Hallo,

auch ich möchte mal meinen aktuellen Stand mitteilen. Mein MVC-Framework nimmt immer mehr Formen, sodass ich bald die ersten Module dafür entwicklen möchte. Vorab bin ich allerdings dabei sog. Programmierrichtlinien kurz schriftlich zu fixieren.

Innerhalb eines Modul-Ordners gibt es drei Unterordner.

1. models

Klassenbennung: class test { }
Dateibennnung: class.test.php

2. views

Dateibennung: action.phtml

3. controllers

Klassenbennung: indexController (nur was ist wenn ich pro Modul einen habe? event_indexController ?!)
Dateibennung: controller.KLASSE.php

Oder habt ihr eine andere Idee für die Namenskonventionen?

__________________
www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen