APFel-SMS - SiteManagementSystem Erweiterung

Dieser Bereich dient dazu, eure Tricks und Erweiterungen vorzustellen, damit diese auch andere Anwender nutzen können. // This area can be used to publish your tricks and extensions to the APF to be used by other developers.
Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von jwlighting » 05.03.2011, 20:08:49

Hallo,

abgesehen von ein paar Klausuren in den Leistungskursen (aber was ist das schon... :roll: ) habe ich nun erstmal nichts zu tun (naja, zumindest möchte ich mir hier für Zeit nehmen).

Während der Entwicklung meiner ersten (und bisher auch einzigen) Website mit dem APF, die ich durchweg ansich sehr angenehm und bequem empfand, fehlte mir dennoch etwas:
Eine Hilfe bei der Erstellung von Navigationen mehrer Ebenen (Unternavigationen), was ich on-the-fly durch Zeitdruck leider nicht umsetzen konnte. Deneben habe ich noch ein paar andere Dinge im Zusammenhang mit Inhaltseiten vermisst, die aber ohne Frage auch eher teil einer Erweiterung sein sollten.

Die entsprechende Erweiterung soll jetzt in aller Ruhe folgen, dabei würde ich auch gerne eure Ideen, Ratschläge und Erfahrungen mit einbringen.

Was soll die Erweiterung können?
  • die Seiten-ID/-alias validieren und bei auf Bedarf eine 404-Seite (Fallback) ausweichen
  • Geschachtelte Seitenstrukturen verwalten und auf Grundlage der aktuellen Seite Navigationen generieren
  • Den Seitentitel, sowie zusätzlich benötigte Seiten-CSS- und Seiten-JS-Dateien in den übergeordneten Templates platzieren (ja, ich weiß, da gibt es schon was...)
  • Links generieren, bei denen das title-Attribut mit dem Seitentitel gefüllt wird
Alle Seiten sollen dabei mit all ihren Informationen sowohl als Dateien (und Ordner) komplett im Dateisystem abgebildet werden, sowie auch aus einer Datenbank stammen können.

Und wie?
Nun geht es ans Konzept. Betrachten wir zunächst die Dateisystem basierte Version: Die Navigationsstruktur wird durch die Ordnerstruktur im Dateisystem wieder gespiegelt. Die Unterseiten zu einer Seite liegen dann jeweils in einem Ordner, der den selben Namen wie die Seite hat, bspw. about.html und about/. Auf Basis dessen werden dann die Navigationen erstellt. Mit ein paar Kniffen durch Textdateien und Dateinamenskonventionen lassen sich URL-Verlinkungen (extern bspw.) und Links zwischen verschiedenen Ebenen hinbekommen (in UNIX-Systemen ist das mit symbolischen Links noch einfacher, aber wir ja Multi-OS-Entwickler ;)), bzw. die Reihenfolge der Einträge festlegen.
Die Validierung der Seiten-ID sollte klar sein: file_exists().
Der Seitentitel sowie zusätzlich benötigte Stylesheets und Scripts lassen sich mit Taglibs abbilden.
Die Linkgenerierung ebenfalls, die zu verlinkende Datei wird angegeben und der Seitentitel ausgelesen (-> Caching?). Das URL-Layout sollte natürlich konfigurierbar sein.

In der Datenbankversion kann man die Navigationsstruktur mit Hilfe von Nested-Sets abbilden. Die einzelnen Seiten werden dabei mit der Navigationsstruktur nur per ID verknüpft, verschiedene Seitentypen erlauben externe Links usw.. In den Einträgen für die Seiten sind dann entweder die Dateinamen der entsprechenden Templates vermerkt, oder es ist darin auch der Inhalt enthalten, ganz, wie es der Anwender wünscht. Im letzteren Fall kann der Seitentitel und CSS-/JS-Dateien dann in eigenen Spalten abgelegt werden, die Linkgenerierung ist über eine Art BBCode machbar.


Soweit mal ein Überblick, wie ich mir das ungefähr gedacht habe.
Was würdet ihr anders machen, wo kann man etwas hinzufügen, flexibler gestalten, und wo seht ihr Designfehler? Freue mich auf eure Rückmeldungen, Ideen und Kritik!!

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von dr.e. » 05.03.2011, 20:26:47

Hallo Jan,

ich persönlich würde die Filesystem-basierte Lösung nicht realisieren, sondern versuchen die Datenbank-Variante so zu bauen, dass du statt der Filesystem-Variante lieber eine Komponente und eine GUI anbietest, mit der mal einen solchen Navigations-Baum einfach verwalten kann.

Ebenso muss hierbei die Möglichkeit geschaffen werden, dass du Seiten (was auch immer das ist) in den Baum einhängen, bzw. an Hand einer Seite bestimmen kannst, wo im Baum du dich befindest und welche Knoten da drumherum sind. Hinsichtlich der Baum-Struktur würde ich zudem versuchen mehrere Implementierungen für einen Baum-Knoten anzubieten, die bei Bedarf angepasst werden (Interface!).

In Summe finde ich das Thema Navigation sehr spannend und für das APF einen schicken Anwendungsfall und eine Bereicherung! :) Mir persönlich würde noch das Thema GUI-Repräsentation am Herzen liegen. Hierüber hatten wir irgendwo im Forum schon mal gesprochen. Ich kann mir hier eine Art Iterator mit Konfiguration für unterschiedliche Levels und Knoten-Typen etc. gut vorstellen.
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von Screeze » 05.03.2011, 20:36:57

Wie wärs statt der FileSystem variante mit einer config-datei variante?

Sowas in der Art:

Code: Alles auswählen

[Level_1] ; basisebene
1.Target = "/whatever.html"
1.Name = "Anzeigename"
1.Extern = "false" ; kann optional sein mit default auf false
2.Target = "http://andrelokale.de/seite.html"
2.Target = "Anzeigename2"
2.Extern = "false"

3.Target = "http://google.de"
3.Name = "google"
3.Extern = "true"

[level_2_1] ; 2. ebene, untermenü von punkt 1 in der Basisebene
...

Mit entsprechender GUI natürlich, geht ja mit den neuen config-funktionen wunderbar

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von jwlighting » 05.03.2011, 22:02:35

Hallo,
ich persönlich würde die Filesystem-basierte Lösung nicht realisieren, [...]
Wäre dann schade für alle Projekte in denen keine Datenbank vorhanden ist, bzw. oversized wäre.
Wie wärs statt der FileSystem variante mit einer config-datei variante?
Klingt gut. Für mich scheint die Dateisystemvariante aber intuitiver und daher gerade für Einsteiger besser geeignet. Was siehst du den für Vorteile bei der Variante mit der Config-Datei?
lieber eine Komponente und eine GUI anbietest, mit der mal einen solchen Navigations-Baum einfach verwalten kann.
Für die Datenbankvariante ist sicher eine GUI notwendig, bei Nested-Sets wird man sonst verrückt, klar!! :D :ugeek:
Wie weit geht den "GUI" für dich? Schon in Richtung eines CMS-Ansatzes (speziell, wenn die Inhalte auch in der Datenbank liegen)? Ich hatte da eher an eine API gedacht, der eine GUI beiliegt die man bei Bedraf nach eigenen Anforderungen verändern kann. Oder das man die API in seiner eigenen Anwendung (-> Backend) verwenden kann.
dass du Seiten (was auch immer das ist)
Ich dachte mir schon, dass es da zu linguistischen Problemen kommen kann... Seite meint hier eine Inhaltsseite, z.B. Über Uns, Kontakt, Portfolio, Home, Produkte, ...
Ebenso muss hierbei die Möglichkeit geschaffen werden, dass du Seiten [...] in den Baum einhängen, bzw. an Hand einer Seite bestimmen kannst, wo im Baum du dich befindest und welche Knoten da drumherum sind. Hinsichtlich der Baum-Struktur würde ich zudem versuchen mehrere Implementierungen für einen Baum-Knoten anzubieten, die bei Bedarf angepasst werden (Interface!).
Ja. Die Daten einer Seite sollen in einer Model-Klasse liegen. Diese weiß dann über die Navigationsstruktur natürlich auch über die Verwandtschaft Bescheid, so wie beim DOM z.B.. Bei NestedSets ist das aber recht einfach machbar. Für verschiedene Typen von Seiten (jetzt im Sinne eines Navigationseintrags, bspw. Externer Link, mit Sprungmarke, etc.) soll es dann eigene, von einer Vaterklasse erbende, Klassen geben.
Mir persönlich würde noch das Thema GUI-Repräsentation am Herzen liegen. Hierüber hatten wir irgendwo im Forum schon mal gesprochen. Ich kann mir hier eine Art Iterator mit Konfiguration für unterschiedliche Levels und Knoten-Typen etc. gut vorstellen.
Das geht dann aber doch schon in Richtung CMS, oder? ;) Ich denke wir sollten hier erstmal einen soliden Grundstock für die Anwendung vom Programmierer schaffen. Wenn man das System dann per GUI konfigurieren will, dann auch richtig, und mit allem was zu einem CMS dazu gehört, sonst hat man hinterher wieder nur halbe Sachen.
Auch wenn ich verstehen kann das dir da viel dran liegt, ein Schritt nach dem anderen. Soll kein generelles nein sein, aber man muss Prioritäten setzen.
Mir geht es erstmal darum, eine Erweiterung zu schaffen die das schnelle Programmieren von Seiten, auch mit größerer Struktur, ermöglicht. darauf kann man dann weiteres aufbauen.

LG :)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von dr.e. » 06.03.2011, 14:44:35

Hi Jan,
Wie weit geht den "GUI" für dich? Schon in Richtung eines CMS-Ansatzes (speziell, wenn die Inhalte auch in der Datenbank liegen)? Ich hatte da eher an eine API gedacht, der eine GUI beiliegt die man bei Bedraf nach eigenen Anforderungen verändern kann. Oder das man die API in seiner eigenen Anwendung (-> Backend) verwenden kann.
Eine offene API ist immer wichtig, ich würde jedoch schon ein Veraltungs-Frontend erwarten, dass sich in meine Anwendung integrieren lässt; dahiner natürlich eine API, die ich auch in meiner Anwendung direkt nutzen könnnte.
Ich dachte mir schon, dass es da zu linguistischen Problemen kommen kann... Seite meint hier eine Inhaltsseite, z.B. Über Uns, Kontakt, Portfolio, Home, Produkte, ...
OK, dann passt das. :)
Das geht dann aber doch schon in Richtung CMS, oder? ;) Ich denke wir sollten hier erstmal einen soliden Grundstock für die Anwendung vom Programmierer schaffen. Wenn man das System dann per GUI konfigurieren will, dann auch richtig, und mit allem was zu einem CMS dazu gehört, sonst hat man hinterher wieder nur halbe Sachen.
Das geht alles in Richtung CMS - korrekt. Aber ich stimme dir zu, zunächst sollte eine saubere API am Start sein und im Frontend ein, zwei Tags, dem du den Baum geben kannst und der dir daraus eine HTML-Struktur bauen kann. Das würde schon für den ersten Schritt ausreichen.
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von jwlighting » 06.03.2011, 16:15:03

Eine offene API ist immer wichtig, ich würde jedoch schon ein Veraltungs-Frontend erwarten, dass sich in meine Anwendung integrieren lässt; dahiner natürlich eine API, die ich auch in meiner Anwendung direkt nutzen könnnte.
Gut, dann deckt sich das aber ja ziemlich mit dem, was ich mir vorgestellt habe. Wenn Datenbank, dann auch mit GUI.
Aber ich stimme dir zu, zunächst sollte eine saubere API am Start sein und im Frontend ein, zwei Tags, dem du den Baum geben kannst und der dir daraus eine HTML-Struktur bauen kann. Das würde schon für den ersten Schritt ausreichen.
Den letzten Teil deines Satzes verstehe ich nicht so ganz, bzw. ergibt er so keinen Sinn. :?:
meinst du, es sollte neben der API Taglibs geben, mit denen man den Navigationsbaum beeinflussen kann?


Wie sieht es jetzt mit einer Dateisystemversion aus? Lasst uns da bitte weiter drüber diskutieren.

LG :)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von dr.e. » 06.03.2011, 17:12:16

Hallo Jan,
Den letzten Teil deines Satzes verstehe ich nicht so ganz, bzw. ergibt er so keinen Sinn. :?:
meinst du, es sollte neben der API Taglibs geben, mit denen man den Navigationsbaum beeinflussen kann?
Mir ging es hier nur um die Ausgabe des Baumes. Beeinflussen können sollte man den Baum nur mit der API selbst - so meine Idee.
Wie sieht es jetzt mit einer Dateisystemversion aus? Lasst uns da bitte weiter drüber diskutieren.
An sich ist die Idee mit dem Dateisystem schon nicht schlecht. Die dort enthaltene Seite kann ja über eine Pseudo-Konfigurations-Datei, die einfach nur den Verweis auf den anzuzeigenden Inhalt beinhaltet, abgelegt werden. Unterordner sind weitere Unterpunkte, die genannte Konfigurations-Datei der Inhalt. Sofern du die Baum-Knoten abstrahierst, kann das sehr einfach durch eine eigene Implementierung erreicht werden.

Die Navigation auf der payback.de habe ich so implementiert, dass der aktuelle Knoten immer über eine NavigationNodeFactory erzeugt wird. Diese weiß um den Umstand (hier die Art der Navigation) und erzeugt dir die richtige Instanz (DBNavigationNode oder FilesystemNavigationNode). Ausgehend von dieser kennt ein Navi-Knoten sein eigenes Verhalten und kann dir seinen Vater oder auch seine Kinder ausgeben. Darüber kannst du dann alles inkl. Breadcrumb-Navi abbilden. Die Ausgabe sollte man dann aber in irgendeiner Form cachen können, sonst wird der Zugriff irgendwann langsam. Wenn ich dir mehr Code-Beispiele posten soll, sag Bescheid.
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von jwlighting » 06.03.2011, 19:37:59

Mir ging es hier nur um die Ausgabe des Baumes. Beeinflussen können sollte man den Baum nur mit der API selbst - so meine Idee.
Super, dann gehen wir wieder konform ;)
Screeze hat geschrieben:Wie wärs statt der FileSystem variante mit einer config-datei variante?
An sich ist die Idee mit dem Dateisystem schon nicht schlecht.
Ich glaube mittlerweile, Screzze hat doch durchaus Recht:
Wenn die Dateien in verschiedenen Ordnern liegen, müssen Dateinamen nicht mehr eindeutig einer Seiten-ID (Alias) zugeordnet werden können - es kann ja mehrere Dateien gleichen Namens in unterschiedlichen Ordnern geben.
Man müsste also die Seite auch über einen Pfad angeben (was aber spezielles URL-Layout erfordert, und mir damit zu vielschichtig und zu schwer für einen Einsteiger wird). Bei der Config-Variante hat man das Problem nicht, die Struktur steht da in der Config. Mehrere Webseiten nebeneinander kommen sich dann auch nicht ins Gehege, und es lassen sich beliebig viele unterschiedliche Navigationsbäume aus den selben Seiten aufbauen (auch wenn das der IA der Webseite nicht immer zu Gute kommen muss...).
Allerdings würde ich dann ein XML-Format (incl. dazugehöriger DTD) verwenden wollen, da das der Baumstruktur wesentlich besser gerecht wird. Man kann sich außerdem überlegen, ob es vielleicht sinnvoll wäre dort wirklich nur die Baumstruktur, und keine Informationen wie Seitentitel etc. zu speichern. Der Seitentitel gehört IMHO semantisch zur Inhaltsseite, lässt sich dort als Taglib also besser darstellen (dort ist er, wo er hingehört und wozu er gehört).
Unterordner sind weitere Unterpunkte, die genannte Konfigurations-Datei der Inhalt.
Meinst du mit "Inhalt" den Inhalt einer Seite, was andernfalls? Dann verstünde ich den Sinn nicht ganz. :|
Diese weiß um den Umstand (hier die Art der Navigation) und erzeugt dir die richtige Instanz (DBNavigationNode oder FilesystemNavigationNode).
Hatte ich mir anders angedacht: Die Elemente der Baumstruktur haben die gleiche Klasse, werden höchstens nach Typ (Link zur Inhaltsseite, Externer Link, etc) unterschieden. Als Eigenschaft haben sie ein Objekt mit einer über ein Interface (oder abstrakte Klasse) festgelegten API, aus der sie sich die Daten besorgen. Dieses Objekt ist also so eine Art Adapter (ich weiß jetzt nicht, ob ich das Wort im Sinne des gleichnamigen Patterns richtig verwende) zwischen der Datenstruktur des Baumknotens und der Datenbank/Configdatei. Je nachdem, woher die Daten kommen, gibt es unterschiedliche Adapterklassen.

LG :)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von Screeze » 06.03.2011, 19:49:16

Genau das meinte ich.
eine XML struktur ist natürlich auch eine Möglichkeit.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von dr.e. » 06.03.2011, 22:52:04

Hallo Jan,
Hatte ich mir anders angedacht: Die Elemente der Baumstruktur haben die gleiche Klasse, werden höchstens nach Typ (Link zur Inhaltsseite, Externer Link, etc) unterschieden. Als Eigenschaft haben sie ein Objekt mit einer über ein Interface (oder abstrakte Klasse) festgelegten API, aus der sie sich die Daten besorgen.

Wenn du doch ein Interface hast, kannst du auch verschiedene Implementierungen anbieten. Das würde auch dem Prinzip separations of concerns entsprechen.
Dieses Objekt ist also so eine Art Adapter (ich weiß jetzt nicht, ob ich das Wort im Sinne des gleichnamigen Patterns richtig verwende) zwischen der Datenstruktur des Baumknotens und der Datenbank/Configdatei. Je nachdem, woher die Daten kommen, gibt es unterschiedliche Adapterklassen.
Adapter wäre das richtige Wort für die Verbindung zwischen Knoten und Inhalt. Weiterhin ist aber das composite pattern für die Konstruktion des Baumes relevant. Wenn du mit einem Adapter arbeitest, musst du diesen aber auch je Typ injizieren. Es wäre also nicht hinderlich eine eigene Implementierung für die Knotentypen zu haben.
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von jwlighting » 07.03.2011, 16:30:01

Wenn du doch ein Interface hast, kannst du auch verschiedene Implementierungen anbieten. Das würde auch dem Prinzip separations of concerns entsprechen.
Meint, das sich möglichst wenig Code überlappt? Hättest du mal ein Beispiel, wie man das umsetzen würde. (Code oder Flußdiagramm)
Wenn du mit einem Adapter arbeitest, musst du diesen aber auch je Typ injizieren
Du meinst je Typ eines Seitenobjektes? (extern, intern, etc. wären Typen) das stimmt soweit.
In beiden Fällen, sowohl für die Seitentypen, als auch für die "Datenbesorger-Adapter" ("-Mapper"??) kann man aber mit Klassenvererbung arbeiten:

Code: Alles auswählen

interface siteDataAdapter{
 // ...
}

class DatabaseSiteDataAdapter implements siteDataAdapter{
 // ...
}

class ConfigSiteDataAdapter implements siteDataAdapter{
 // ...
}


abstract class SiteNode{
 private $__dataAdapter;

 abstract function __construct(siteDataAdapter $__dataAdapter){
   // ...
 }

 // ...
}

class InternSiteNode extends SiteNode{
 // ...
}

class ExternSiteNode extends SiteNode{
private $__dataAdapter;

function __construct(externSiteDataAdapter $__dataAdapter){
   // ...
 }

 // ...
}

interface externSiteDataAdapter{
 protected $_externURL;

 // ...
}

class ExternDatabaseSiteDataAdapter extends DatabaseSiteDataAdapter implements ExternSiteDataAdapter{
 // ...
}
 
 
Zuletzt geändert von jwlighting am 10.03.2011, 17:35:29, insgesamt 1-mal geändert.

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von dr.e. » 07.03.2011, 19:10:00

Hi,

wenn du mit einem Adapter arbeitest brauchst du sowas:

Code: Alles auswählen

interface NavigationNode {
   public function __construct(DataAdapter $adapter);
}

interface DataAdapter {
   public function getSource();
}

class DatabaseNavigationAdapter implements DataAdapter {
}

class FilesystemNavigationAdapter implements DataAdapter {
} 
Allerdings musst du dann bei jedem Erzeugen eines NavigationNode den Adapter injizieren. Das sollte dann eine geeignete Factory übernehmen.

Soweit für dich nachvollziehbar?
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von jwlighting » 08.03.2011, 18:13:57

Hallo Christian,

ich glaube das große Problem meines Verständnisses und evtl. Missverständnisse liegen daran, das ich mit den ganzen Begriffen der Design-Patterns nicht sehr vertraut bin.
Vielleicht magst du das daher zusätzlich erläutern, damit wir nicht aneinander vorbei reden und ich verstehe wie das Pattern funktioniert und was du meinst. Sorry. :oops:
Vielleicht magst du auch den Unterschied (-> Vor-/Nachteile) unserer beiden Codebeispiele dazu benutzen.

Um nicht in den Begrifflichkeiten unterzugehen, beschreibe ich jetzt nochmal ohne Design-Pattern-Namen, was ich vorhabe, danach reden wir dann drüber, wie wir das implementieren und was es zu verbessern gilt, OK? Ich muss halt noch eine Menge lernen.

Es gibt verschiedene Typen von Seiten, z.B. Intern, Extern etc..
Es gibt verschiedene Datenquellen, z.B. XML-Strukturen oder eine Datenbank.

Jeder Typ wird nur einmal aus einem abstrakten Basis-Typen implementiert:

Code: Alles auswählen

abstrakt class baseNavigationNode{
}

class InternNavigationNode extends baseNavigationNode{
}

class ExternNavigationNode extends baseNavigationNode{
}
 
Damit jeder Typ mit beliebigen Datenquellen arbeiten kann, bekommt er ein Objekt mit einer bekannten API, die ihm als Mediator zwischen der Datenquelle und sich selbst dient.
Er bezieht seine Daten aus diesem Mediator und der Mediator weiß, wie er mit der jeweiligen Datenquelle umgehen muss. Der Mediator ist also eine vermittelnde Instanz zwischen Datenquelle und Typ.

Code: Alles auswählen

abstrakt class baseNavigationNode{
    public function __construct(navigationDataMediator $mediator);
}
 
Wenn ein Typ zusätzliche, vom Basistyp abweichende Daten benötigt, wird entsprechend ein auf einem Basis-Mediator aufbauender Mediator mit der zusätzlich benötigten Funktionalität verwendet.

Drehen wir uns im Kreis? :|
Btw.: Wie leite ich PHP-Codes ein?

LG :)
Zuletzt geändert von jwlighting am 10.03.2011, 17:34:06, insgesamt 2-mal geändert.

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von jwlighting » 10.03.2011, 16:36:58

Btw.: Wie leite ich PHP-Codes ein?
Da habe ich mich missverständlich ausgedrückt. Ich meine hier im Forum, <?php und ?> ist mir schon klar, falls das falsch verstanden wurde ;)

Mich beschleicht das Gefühl, ich hätte den Thread mit meinem letzten Post gegen die Wand gefahren. In diesem Buch habe ich bei Thalia mal geblättert. Was ich meine ist nicht das Adapter-Pattern, sondern das Data-Mapper-Pattern. das Buch steht jetzt oben auf meiner Wunschliste, damit ich mich eurem Niveau ein wenig anpassen kann und ihr mir dann zukünftig nicht alles auseinanderpflücken müsst, sorry.

Außerdem sollte in die Erweiterung noch eine Möglichkeit eingebaut werden, Navigationseinträge zu verstecken und bei der Validierung der Seiten-ID eine Möglichkeit zur Authorisierungskontrolle gegeben sein, um ggf. 403-Meldungen bzw. ein Loginform etc. zu zeigen.

LG :)
Zuletzt geändert von jwlighting am 10.03.2011, 17:36:17, insgesamt 1-mal geändert.

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: APFel-SMS - SiteManagementSystem Erweiterung

Beitrag von Screeze » 10.03.2011, 17:06:48

Ich kann momentan nur was zu der php-formatting geschichte im forum sagen:
ohne das * -> dann wirds farbig

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast