[Erledigt] Module SW Design (Standard vs. Customized vs. Wartbarkeit mit SVN)

robotron · 06.05.2009, 11:58

Hallo zusammen

Wir haben ein kleines CMS Framework zusammengeschustert, dass schon ziemlich gut läuft. Leider haben wir gemerkt das die Wartung eher schwierig ist, vorallem bei den Modulen. Das Problem beschreibe ich unten genauer!

Grundsetup CMS

Vereinfacht gesagt kommt ein Request rein (GET/POST, Soap, Ajax etc.). Dieser Request wird von einem HTTPHandler angenommen, durch URLRewrite interpretiert und vom HTTPHandler mit einem Request und einem Response Objekt zur Verarbeitung weitergeleitet an die Module. Diese befüllen das Response Objekt welches der HTTPHandler dann ausgibt. Wir setzen Smarty ein zur Trennung von Logic/Code wenn es um die Htmlausgabe geht.

Hänge hier noch ein Bild rein, ist keine vollständiges und korrektes Diagramm - aber es zeigt hoffentlich die Idee:

Unabhängige Module

PHP-Code:

  interface ModuleInterface 
{
    public function __construct($pRequest, $pResponse, $pParams = '', $pLayout = array());
}

Jedes Modul:
- implementiert das obige interface
- kann völlig eigenständig arbeiten
- hat generische klassen für frontend/backend
- trennt implementationsklassen für frontend/backend
- hat benötigte smarty templates für frontend/backend
- hat eigenes configfile
- hat eigenes language file

Kurze Geschichte des Scheiterns bei Wartung und SVN

Für jedes Kundenprojekt haben wir ein neues SVN Repository angelegt und das Cms reinkopiert. Das war ein Fehler, denn nun müssen wir einen Bugfix in jedem Repository einzeln einspielen - Mist. Also machen wir eine neues Konzept um Bugfixes effizienter zu verteilen

:
Zuerst trennen wir die Kundenspezifischen von den Core Teilen. Wir reissen also das CMS auseinander und bekommen einen cmscore (Standard) und ein cmscustom (Individuell). Das customcore wird geshared und so erhält jedes cms die Bugfixes für customcore - das finden wir prima soweit.

Neues SVN Setup, neue Modulanforderungen

Wir haben möchten neu nur noch ein SVN Repository und neue Projekte werden jeweils aus dem Revisionbranch des cmscustom in ein neues Projekt kopiert (cool weil mit svn hier die files nicht kopiert sondern refernziert, history bleibt erhalten, ausserdem kann so auch besser mergen). Hier das neue Setup:

Endlich kommt das Modulproblem

In der neuen Struktur seht ihr module_core und module_custom. Unser Problem ist: Wie können wir eine Standardmodul für einen Kunden so anpassen, dass er gewünschte Graphik, Specialfeatures etc. des Moduls erhält während wir gleichzeitg möglichst viel vom Standardmodul nutzen, damit Bugfixes am Core auch bei allen Kunden eine Wirkung zeigen.

Ich glaube wir müssen die Module komplett neu aufbauen - aber ich habe ne totale Hirnblockade wie wir das schlau anstellen sollen. Hier noch eine Auszug wie ein Modul momentan aussieht:

So ich hoffe dass es einigermassen verständlich ist und das Problem nachvollziehbar wird. Ich bin echt froh um Inputs wie Ihr sowas lösen würden, generelle Hinweise für geeignete Design Patterns/Architekturen oder eigene Erfahrungen etc.

So long
robotron

dr.e. · 06.05.2009, 22:49

Hi robotron,

zunächst würde ich Code-Verwaltung und Deployment/Verwendung etwas trennen. SVN selbst bietet da mit den externals die Möglichkeit, externe Repos wie lokale einzubinden. Das funktioniert auch mit "eigenen externen" Repos, die z.B. euer Core-Projekt enthalten.
Ist das nicht möglich/gewünscht, so würde ich für das Core-Projekt aus dem SVN ein Build bauen, das lokal "installieren" und nur die Projekt-relevanten Sourcen aus dem Projekt-SVN beziehen. Das kann dann so aussehen:

Code:

/libs/core/...
/libs/project1/...
/libs/tools/...

Der Ordner project1 ist dabei unter SVN-Verwaltung, die anderen nicht, da sie aus einem Build stammen. Alternativ kannst du dazu natürlich auch core und tools aus dem Core-Projekt-SVN auschecken und so lokal arbeiten und Bugfixes bzw. Erweiterungen einfach zurückspielen. Um lokal das APF zu testen, verwende ich auch einen lokalen Checkout des Codes und linke diesen in konkreten (Test-)Projekten in den Verzeichnisbaum. Das funktioniert hervorragend und spart Arbeit. Wichtig ist dabei nur, auf die Symlinks ein wenig Acht zu geben, wenn du mit unterschiedlichen Builds arbeitest.

Zitat:

In der neuen Struktur seht ihr module_core und module_custom. Unser Problem ist: Wie können wir eine Standardmodul für einen Kunden so anpassen, dass er gewünschte Graphik, Specialfeatures etc. des Moduls erhält während wir gleichzeitg möglichst viel vom Standardmodul nutzen, damit Bugfixes am Core auch bei allen Kunden eine Wirkung zeigen.

Die Lösung ist IMHO trivial: saubere Schnittstelle zum Einklinken von Modulen schaffen und Konfigurationen für Projekt-spezifische Dinge wie Bilder etc. einführen. Weiterhin sollten die Funktionen so gestaltet werden, dass diese maximal wiederverwendet werden können. Das funktioniert zum einen mit der Bereitstellung einer generischen Konfigurationsmöglichkeit und zum anderen durch Disziplin beim Refactoring. Sehe ich als Entwickler, dass ich eine Funktion wiederverwenden kann, werde ich das auch im Kundenprojekt so umsetzen, dass im nächsten dies nicht nochmal entwickelt werden muss.

Hier vielleicht noch ein paar Anregungen zur Modularisierung auf der APF-Seite:

Viele Grüße,
Dr.E.

robotron · 18.05.2009, 15:20

Hi Dr.E.

Vielen Dank für Deine Antwort. Ich habe mir svn externals angesehen, sehr gut zu wissen.

Wir sind nun am "Refactoring" und haben ein eigenes shared repo und ein custom repo für alle client Projekte. Die Module rufen wir mit einer Factory auf (core/custom), die Implementation leitet von den Coremodulen ab.

Es waren gute Inputs von Dir, auch das APF sieht sauber und spannend aus. Werde sicherlich hin und wieder reingucken - Thanks man

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Design und Code Trennen	TeazY	PHP Tipps 2008	29	21.05.2008 12:08
Design		Beitragsarchiv	26	04.06.2005 20:56

06.05.2009, 11:58
robotron Neuer Benutzer Registriert seit: 06.05.2009 Beiträge: 2	[Erledigt] Module SW Design (Standard vs. Customized vs. Wartbarkeit mit SVN) Hallo zusammen Wir haben ein kleines CMS Framework zusammengeschustert, dass schon ziemlich gut läuft. Leider haben wir gemerkt das die Wartung eher schwierig ist, vorallem bei den Modulen. Das Problem beschreibe ich unten genauer! Grundsetup CMS Vereinfacht gesagt kommt ein Request rein (GET/POST, Soap, Ajax etc.). Dieser Request wird von einem HTTPHandler angenommen, durch URLRewrite interpretiert und vom HTTPHandler mit einem Request und einem Response Objekt zur Verarbeitung weitergeleitet an die Module. Diese befüllen das Response Objekt welches der HTTPHandler dann ausgibt. Wir setzen Smarty ein zur Trennung von Logic/Code wenn es um die Htmlausgabe geht. Hänge hier noch ein Bild rein, ist keine vollständiges und korrektes Diagramm - aber es zeigt hoffentlich die Idee: Unabhängige Module PHP-Code: `interface ModuleInterface { public function __construct($pRequest, $pResponse, $pParams = '', $pLayout = array()); }` Jedes Modul: - implementiert das obige interface - kann völlig eigenständig arbeiten - hat generische klassen für frontend/backend - trennt implementationsklassen für frontend/backend - hat benötigte smarty templates für frontend/backend - hat eigenes configfile - hat eigenes language file Kurze Geschichte des Scheiterns bei Wartung und SVN Für jedes Kundenprojekt haben wir ein neues SVN Repository angelegt und das Cms reinkopiert. Das war ein Fehler, denn nun müssen wir einen Bugfix in jedem Repository einzeln einspielen - Mist. Also machen wir eine neues Konzept um Bugfixes effizienter zu verteilen : Zuerst trennen wir die Kundenspezifischen von den Core Teilen. Wir reissen also das CMS auseinander und bekommen einen cmscore (Standard) und ein cmscustom (Individuell). Das customcore wird geshared und so erhält jedes cms die Bugfixes für customcore - das finden wir prima soweit. Neues SVN Setup, neue Modulanforderungen Wir haben möchten neu nur noch ein SVN Repository und neue Projekte werden jeweils aus dem Revisionbranch des cmscustom in ein neues Projekt kopiert (cool weil mit svn hier die files nicht kopiert sondern refernziert, history bleibt erhalten, ausserdem kann so auch besser mergen). Hier das neue Setup: Endlich kommt das Modulproblem In der neuen Struktur seht ihr module_core und module_custom. Unser Problem ist: Wie können wir eine Standardmodul für einen Kunden so anpassen, dass er gewünschte Graphik, Specialfeatures etc. des Moduls erhält während wir gleichzeitg möglichst viel vom Standardmodul nutzen, damit Bugfixes am Core auch bei allen Kunden eine Wirkung zeigen. Ich glaube wir müssen die Module komplett neu aufbauen - aber ich habe ne totale Hirnblockade wie wir das schlau anstellen sollen. Hier noch eine Auszug wie ein Modul momentan aussieht: So ich hoffe dass es einigermassen verständlich ist und das Problem nachvollziehbar wird. Ich bin echt froh um Inputs wie Ihr sowas lösen würden, generelle Hinweise für geeignete Design Patterns/Architekturen oder eigene Erfahrungen etc. So long robotron Geändert von robotron (06.05.2009 um 12:30 Uhr). Grund: SW Design und Architektur für Modulproblem finden


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

18.05.2009, 15:20
robotron Neuer Benutzer Registriert seit: 06.05.2009 Beiträge: 2	Hi Dr.E. Vielen Dank für Deine Antwort. Ich habe mir svn externals angesehen, sehr gut zu wissen. Wir sind nun am "Refactoring" und haben ein eigenes shared repo und ein custom repo für alle client Projekte. Die Module rufen wir mit einer Factory auf (core/custom), die Implementation leitet von den Coremodulen ab. Es waren gute Inputs von Dir, auch das APF sieht sauber und spannend aus. Werde sicherlich hin und wieder reingucken - Thanks man