Factory- und Adapter Pattern für die Erweiterung von WordPress
3. Juni 2009 Roland
- Erstellen eines Newssystems
- Akteure im Newssystem
- Newssystem Anwendungsfälle für den Systemadministrator
- Newssystem Anwendungsfälle für den Editor
- Newssystem Anwendungsfälle Zusammenfassung
- Newssystem Anwendungsfälle Webuser
- Anwendungsfall Add Category
- Anwendungsfall Add Editor to Category
- Anwendungsfall Change Editor
- Nebenläufigkeiten beim Editieren von Newseinträgen
- Anwendungsfall Create Editor
- Anwendungsfall Delete Category
- Anwendungsfall Delete Editor
- Anwendungsfall Edit Category
- Anwendungsfall Remove Editor From Category
- Anwendungsfall Show Editors
- Anwendungsfall Show Categories
- Anwendungsfall Add Image to Newsentry
- Anwendungsfall Create Newsentry
- Anwendungsfall Delete Image
- Anwendungsfall Delete Newsentry
- Anwendungsfall Edit Image Data
- Anwendungsfall Edit Newsentry
- Anwendungsfall Navigate in Newslist
- Anwendungsfall Remove Image from Newsentry
- Anwendungsfall Search Image
- Anwendungsfall Search News
- Anwendungsfall Set Presentation Times
- Anwendungsfall Upload Image
- Anwendungsfall Navigate Archive News Shortentries
- Anwendungsfall Navigate Shortentries
- Anwendungsfall Show Archive Newsentry
- Anwendungsfall Show Newsentry
- Anwendungsfall Show Shortentries
- Aufbereiten der bisherigen Anwendungsfälle
- Technische Anwendungsfälle
- Nebenläufigkeiten beim Lesen von Newseinträgen
- Lasst uns mal über Performancemessung reden
- Erste Gedanken zum Backup und Restore für unser Newssystem
- Zwischenschicht zur Performancemessung einbauen
- Performancemessungen ein- und ausschalten
- Performance Messung auf dem Server durchführen
- Newssytem Daten Modellieren
- Anwender Aktionen loggen
- Geschäftsmodelle erkennen
- ImageModel Beschreibung
- Installierbarkeit des Newssystems
- Housekeeping im Newssystem
- Anwendungsfall SearchNotUsedImages
- UserModel Beschreibung
- Meldungsverwaltung und Severity Bestimmung im Newssystem
- UserModelFactory
- Einsatz eines Frameworks für die Erstellung des Newssystems
- Ist das Newssystem einfach nur eine View auf eine Blogsoftware?
- Factory- und Adapter Pattern für die Erweiterung von WordPress
- Wieso will ich das Newssystem nicht als WordPress Plugin erstellen?
- Newssystem gesundschrumpfen
- Wer sind unsere Kunden für das Newssystem?
- Requirements für Newssystem erfassen
- Rahmenbedingungen für das Newssystem
- Entscheidung wie das Newssystem jetzt umgesetzt werden soll
- Welche Tools können wir zur Anforderungsverwaltung einsetzen?
- Verwalten der Anforderungen
- Namensänderungen im Newssystem Modell
- Ein Tool für die Anforderungen
- Komponenten die im ersten Sprint umgesetzt werden sollen
- Auf der Suche nach einem Tool um Anforderungen zu erfassen
- Security fummelt man am Besten gleich in die Architektur hinein
- Security Komponenten Klassendiagramm
- wie schrumpft man das System Gesund?
Ich habe gestern im Artikel Ist das Newssystem einfach nur eine View auf eine Blogsoftware darüber gegrübelt dass ich mit dem Newssystem eigentlich nur eine Erweiterung von WordPress beschrieben habe.
Vermutlich trifft das Newssystem am ehesten auf WordPress MU oder BuddyPress zu. Aber schlussendlich ist es nichts weiter als WordPress ein bisschen anders angesteuert und dargestellt.
Was für Erkenntnisse habe ich heute?
Ich habe mittlerweile erkannt, dass ich am Wochenende am Barcamp in Dornbirn locker über die Modularisierung und Benutzung von bestehenden Systemen sprechen kann.
Am Beispiel des Newssystems müssen vermutlich nur
- Ein Endedatum, an dem die News (der Artikel) nicht mehr dargestellt werden darf.
- Eine einfache Eingabe für die News, also keine komplette WordPress Eingabe sondern wirklich nur Titel und Beschreibung sowie Start- und Endedatum.
- Einige Views, mit denen die News Einträge überall ohne das komplette WordPress Verhalten angezeigt werden können. Dies kann über RSS Feeds oder über explizit entwickelte Views erreicht werden.
Wie könnte man WordPress entsprechend einbinden?
Nichts leichter als das!
Wir nehmen eine Factory Klasse, die uns für die unterschiedlichen WordPress Versionen die entsprechenden Adapterklassen anzieht.
Auf diese Weise sind wir vom WordPress entkoppelt und erhöhen nicht die Komplexität bei einem Update.
Das Ganze könnte ungefähr so aussehen:
Ich erstelle einen Adapter, oder eventuell eine Fassade, mit der die Komponenten von WordPress oder BuddyPress an mein eigenes System angepasst werden.
Da sich während eines WordPress Updates die Schnittstellendefinition verändern kann, wird pro WordPress Version ein dafür notwendiger Adapter oder Fassade geschrieben.
Falls sich nichts ändert, kann natürlich der gleiche Adapter verwendet werden.
Über eine Fabrikklasse kann die im Moment aktive Adapterklasse instanziiert und zurückgeliefert werden.
Die Fabrikklasse kann relativ einfach die Version des aktuell verwendeten WordPress auslesen und entsprechend den richtigen Adapter zurückliefern.
Cool oder?
Wie sieht es mit der Komplexität aus?
Auf dem Fucamp in Furtwangen habe ich über «Ist das Newssystem einfach nur eine View auf eine Blogsoftware? Wieso will ich das Newssystem nicht als WordPress Plugin erstellen?»
Der Beitrag wurde
am Mittwoch, den 3. Juni 2009 um 18:41 Uhr veröffentlicht
und wurde unter Design Pattern, IT, Programmieren abgelegt.
Dir gefiel der Artikel? Dann abonniere doch den RSS Feed Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen.
Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.
Artikel mit ähnlichen Schlagwörtern
...deine Chance den ersten Kommentar zu schreiben... ;-)
Schreibe mir
