mepeisen

Einarbeitungsaufwand sollte man schon rechnen, unbedingt. Da auch der Programmieransatz durchaus neu ist (vergleichbar etwa die Lernkurve beim Umstieg eines erfahrenen Entwicklers von Funktions-Prograamierung zu OOP).

An Nachteilen gibt es außer denen, wo mir wie gesagt Eclipse mittlerweile sehr gut hilft, eigentlich bisher keine. Außer dass es noch etwas neu ist und für große Projekte aus Performance-Gründen evtl. insgesamt noch nicht zu empfehlen. Aber das sind viele Frameworks nicht, wenn man sie falsch verwendet

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Mister Ad

nikosch

Ich halte Konfigurationen grundlegend für sinnvoll, wobei es dabei sehr schnell sehr komplex werden kann. Der Einwand von xm22 ist hier sehr richtig.

Hier scheinen mir 2 von 3 Punkten etwas am Thema vorbeizugehen. Überschriften, Buttonbeschriftungen, Labels, Fehlertexte … sollte man grundlgend immer auslagern (ob man das jetzt Konfiguration oder wie auch immer nennt).

Buttons z.B. sind doch stets der selbe Code, nur Funktion und Beschriftung sind verschieden. Nicht zu vergessen wird spätestens bei einer Lokalisierung ohnehin flexibler Text notwendig. Das kann man doch problemlos einbauen.

Tabellenansichten scheinen mir ein typisches Szenario für Konfigurationen 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.
--

mepeisen

Du kannst auch so argumentieren, dass Tabellenanpassungen Teile des Layouts und Templates sind und als solche auch im Core nichts zu suchen haben. Es gibt da drei Szenarien.
1. Design/Sprachanpassungen (wie ihr schon angemerkt habt)
2. Inhaltsanpassungen ohne zusätzliche Daten. Kann man ans Layout und an geschickte Templatings verweisen. Aber das Problem ist hier: Was sind das für Daten. Sind das Daten, die man sich "zurechtfantasiert" (damit meine ich angepasste Tabellen, die aus verschiedenen Domänen hergeleitet, also vom Controller berechnet werden) oder sind es Daten, die eins zu eins einem Modell entsprechen und wo man nur 5 von 50 möglichen Attributen anzeigt, weil sonst die Tabelle zu breit und unübersichtlich wird?
3. Daten-Erweiterungen. Also wirklich das Einführen eines neuen Attributs nur für einen Kunden. Spätestens hier sind Anpassungen am Core notwendig.

Nehmen wir ein Beispiel: Ein News-Post. Der News-Post als solches besteht aus
- Titel
- Text
- Author
- Datum
In der Tabelle wird Titel, Author, Datum angezeigt.

Ein zweiter Kunde wünscht eine Erweiterung, dass News-Artikel bewertbar sind (0 bis 5 Sterne). In der Tabelle soll die durchschnittliche Bewertung angezeigt werden. Du hast also plötzlich eine Erweiterung, die ein neues Model hinzufügt, nämlich "Bewertung". Und die hier plötzlich an deinem Modell zwei neue Attribute hinzufügt:
- Summe Sterne
- Anzahl Bewertungen
Für die Tabelle musst du nun eine Spalte berechnen:
- runden (Anzahl Sterne durch Anzahl Bewertungen)

Was das Beispiel zeigen soll: Es kommt stark drauf an, von welchen Erweiterungen wir sprechen, denn je nachdem, wovon wir sprechen kann eine andere Empfehlung Sinn machen. Ein pauschales Plugin-Konzept um alle Varianten durchzuexerzieren ist kaum sinnvoll und kaum lösbar.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

nikosch

Korrekt. Aber das hat ja nichts mit der Bibliothek/dem Core zu tun?!

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

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

mepeisen

Ja, aber es hat mit der Frage nach dem Plugin-Mechanismus zu tun, denn: Wie kann das Core etwas ausgeben, von dem man erst durch ein Plugin alles beisammen bekommt? Das Core sollte nie die Plugins persönlich kennen.
Aber was ich eigentlich sagen wollte: Es wird immer Punkte geben, an die ein Plugin gerne eingreifen würde, es aber technisch nicht kann, weil das Core-Modul nicht auf die Idee kommt, eine Plugin-Erweiterung anzubieten. Deswegen pauschal immer und überall Plugin-Schnittstellen anbieten selbst wenn man gar nichts in Plugins erweitert ist albern, langsam und macht den Code unübersichtlich. Genau da würde dann AOP helfen. Zumindest solange du ein klares OOP-Modell hast.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Schneidi

@ nikosch

Ok das Beispiel Buttons war wirklich blöde aber auch nur so schnell aus der Luft gegriffen. Ich habe natürlich im Zuge der Lokalisierung dynamische Texte im System.

@ mepeisen

Das ist noch einmal ein sehr gutes Beispiel für die Problematik mit der ich mich zusätzlich befassen muss.
Der bisher angesprochene Ansatz behandelt nur ein interpretative Plugins, die quasi aus dem Modell zusätzlich infos anbieten sollen.

Ich wollte es für den Anfang erstmal simpel halten, um die grundlegenden Möglichkeiten rauszuarbeiten.

Mit dem Thema wird es jetzt natürlich etwas komplexer.
Wenn ich dem Kunden ein Bewertungssystem oder dergleichen zur Verfügung stellen muss, komme ich in dem Moment nicht um Datenbankveränderungen umher.

Hier könnte ich sagen, ich erweitere das Basis Datenmodell so, das Bewertungen möglich sind. Aber will ich das, wenn nur ein einziger Kunde die Änderungen wirklich braucht ?
In diesem Fall lassen wir pro Kunde eine separate Datenbankinstanz laufen.
So dass ich für Kunde X eine Instanz habe und für Kunde Y eine andere.
So hätte ich die Grundlage zu sagen, ich designe die Änderung als Modul, das sowohl die Plugins für die Präsentation enthält als auch die entsprechend notwendigen Datenbankänderungen.
Hier bräuchte ich allerdings zusätzlich ein Modul, dass die ... ja Modulverwaltung übernimmt. Das heißt ich kann per Config oder dergleichen, die aktiven Module definieren, die sich dann per installationsscript automatisch installieren.

Hierbei sehe ich allerdings das Problem Zeitrahmen wieder auf mich zu kommen.
Deshalb zu diesem Thema vielleicht noch die Bitte nach alternativen Ideen.
Wie würdet ihr den Zusammenhang zwischen "Plugin" und Datenbankänderungen verwalten ?

PS:
Ein großen Problem ist derzeit noch die Tatsache, dass ich den Core nicht allein entwickelt habe und sogar später erst hinzu gezogen wurde.
Das heißt ich habe schon mit vielen Vorgaben auskommen müssen, die ich für ungünstig erachte. Leider fällt jetzt erst auf, das das Grunddesign nicht das optimalste ist, deshalb ist meine Aufgabe jetzt das System noch irgendwie dynamischer zu gestallten.

Problem hierbei ist nur der Zeitliche Rahmen. Also für gute Ideen bin ich immer dankbar.

mepeisen

Ich würde da pragmatisch rangehen. Denn eine Ideallösung gibt es meiner Erfahrung nach nicht. Ich würde drei Varianten vorsehen:

1. Erweiterungen im Template selbst. Diese müssen durch geschicktes templating möglich sein und zur Not bekommt ein Kunde sien spezielles Template. Das ist eine administrative Aufgabe, die sinnvoll zu verwalten. Mit vernünftigen Engines, Smarty usw. ist das möglich.

2. Hooks. Hier einen allgemeingültigen Weg unterstützen, über welche Schnittstelle Hooks angeboten werden und wie sie von einem Plugin genutzt werden/ implementiert werden. Eclipse selbst bietet hierfür nicht nur Methodenaufrufe an, sondern auch Konfigurationsschnittstellen. Die "Extension Points" in Eclipse können also auch irgendeine XML-Konfiguration von einem Plugin erhalten und damit etwas sinnvolles anstellen. Ich halte so etwas für zielführender als eine reine "Ruf mir Methoden auf" Schnittstelle.
Sobald man Bedarf hat, wird an exakt der Stelle, wo der Bedarf ist, der Hook eingebaut.

3. Datenbankerweiterungen.
Hier wird es schwierig. Die Ideallösung gibt es schlichtweg ohne weiteres nicht. Ich hab viel gesehen und immer auch Nachteile. Hier würde ich pragmatisch rangehen. Also versuchen aus einer Spezialanforderung eines Kunden einen allgemeinn Bedarf abzuleiten oder ebend genau das machen: Datenbank-Erweiterung und Hilfsmodul hierfür für exakt diesen Kunden.
Das Negativ-Beispiel in dem Bereich finde ich Typo3V4. Das ist arg grauselig, was es anstellt. Also von der Entwicklungsseite her arg grauselig.
Alles andere läuft darauf hinaus, dass sich die Datenbank selbst verwaltet, dass du dich also von den Zwängen der Datenbank löst und dass du über OOP eine Persistenz-Schicht anbindest, die mit Plugin-Konzepten umgehen lernt. Das ist vom Zeithorizont her nervig. Und es stellt sich die Frage, ob man dann nicht alles gleich auf ein anderes Framework umstellt. Doctrine, Yii oder das von mir bevorzugte Flow3.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Schneidi

@ mepeisen

Ok, dank dir für die Tips, werd mir hierzu eine möglichst saubere und schnell umzusetzende Variante ausdenken. Dann wird es eben nicht das Musterbeispiel für Erweiterbarkeit, aber die Zeit ist halt nicht da.

Danke jedenfalls dafür.
Jetz weiß ich zumindest, dass es wohl keine Musterlösung dafür gibt.

Gruß
Jan

notyyy

ich bevorzuge eine lösung welche aus einem DiC besteht um klassen auszutauschen oder zu decorieren und einem klassischen event system.

DiC: http://anydi.ainfach.de/basics (umstritten + von mir )