[bobby]

Hallo,

da ich gerade an einer neuen Version meines Frameworks sitze möchte ich gleich einige Änderungen einbauen, vorallem die Konfigklasse.

Bisher hat der Zugriff etwa so funktioniert

PHP-Code:

$config->load('meineconfig.php', 'main'); //Laden der Configdatei
$config->PHP = true; //Laden der Unterklasse "Config_PHP"
$config->get('database', 'main')->get('drivers')->fetch('mysql'); 


Nun finde ich die Zeile "$config->PHP = true" nicht sehr schön, da mann ja den Konfigurationstyp direkt beim Laden angeben kann.

PHP-Code:

$config->load('meineconfig.php', 'main', 'PHP'); 


Soweit so gut. Aber intern werden in der Klasse "Config" alle Aufrufe per "__call" an die entsprechende Unterklasse weitergeleitet, nun wird anhand des Indexes (hier "main") die Unterklasse ermittelt.

Ich müsste mich also auf eine bestimmte Stelle verlassen, auf der ich im Argumentenarray den Index ('main') finden kann - das möchte ich aber vermeiden.

Wie würdet ihr eine Schnittstelle für verschiedene Konfigtypen erstellen?

bobby.

[Ben]

Ne, habe ich nicht so ganz verstanden. Was genau ist das Problem? Was stellt denn bislang das $config->PHP = true; dar? Dass die Daten in einer PHP-Datei als Array hinterlegt sind oder was?

Schau dir eventuell mal das Prinzip von Zend_Config an. Vielleicht hilft es ...

[Basti]

Ich über gebe meinem Config-Objekt nur den Pfad, in dem die Konfigurationsdateien liegen (genauer gesagt mehrere Verzeichnisse, denn es gibt ein globales Config-Verzeichnis und eines je Site). Per mixed Config::get(string section, [string varname]) greife ich auf Werte zu, wobei alle Werte einer "section" in einer Datei im besagten Verzeichnis liegen. Wurden die Werte einer section noch nicht geladen, schaue ich halt nach einer Datei im Verzeichnis und benutze je nach Dateiendung eine bestimmte Methode, die Datei einzulesen. Da das im Moment ausschließlich PHP-Dateien sind, war das eigentlich unnötig, das so umzusetzen (!= YAGNI), aber … natürlich ließe sich hier auch gleich je "section" oder eben Konfigurationsdatei eine Klasse vom entsprechenden Typ bauen, die dann im zentralen Config-Objekt gespeichert bleibt.

Nochmal kurz und knapp:
Warum nicht anhand der Dateiendung entscheiden, welche Klasse eine Quelle auslesen kann?

Basti

[bobby]

Hi,

Zitat von Basti

Nochmal kurz und knapp:
Warum nicht anhand der Dateiendung entscheiden, welche Klasse eine Quelle auslesen kann?

Basti

Genau das habe ich mir auch gedacht:

PHP-Code:

$config->load("configuration.php", "system"); 


Die Datei "configuration.php" ist nun an den Index "system" gebunden und der Index ist an die Klasse "Config_PHP" gebunden.

D.h. jetzt greife ich mit

PHP-Code:

$config->get("database", "system")->fetch("host"); 


über die Klasse "Config_PHP" auf die Datei "configuration.php" zu. Bis hier ist es kein Problem.

Nur das ich (fast) alle Aufrufe der Klasse Config per __call an die jeweilige Unterklasse weiterleite. Es wird anhand des Indexs (z.B.: system) entschieden, an welche Unterklasse es weitergeleitet wird und da liegt das Problem. In der Methode __call stehen mir alle übergebenen Argumente nur als Array zur verfügung, woher weiß ich nun welcher davon mein Index ist, denn ich dann für die Weiterleitung benötige?

Ich glaube der Weg über __call ist nicht der Beste, aber mir will gerade auch kein passendes Pattern dafür einfallen.

@Ben: "$config->PHP = true;" war/ist dafür da der Klasse Config mitzuteilen, dass alle folgenden Aufrufe über die Klasse Config_PHP gehen sollen. Das Prinzip von Zend_Config ist nicht ganz das, was ich suche. Ich möchte das alles (zumindest nach außenhin) über die Klasse Config läuft.

bobby

[Basti]

Wie viele öffentliche Methoden hast du denn da? Mir fällt da nicht mehr ein, als get() und set(). In jedem Fall aber besitzen ja alle konkteren Config-Klassen die gleiche Schnittstelle, denn der Client von Config weiß ja nicht, welche konkrete Klasse die Daten ausliest. Sieht so aus, als läge da dein Problem.

Folglich: gemeinsames Interface für alle Klassen definieren, die Config-Daten aus den jeweiligen Quellen auslesen und verändern können (Config_PHP, Config_XML etc.). Somit greifst du aus Config heraus immer nur auf dieses Interface zu und brauchst garnicht zu wissen, was für eine Klasse das denn nun konkret ist (außer beim Bauen eben).

Zeig doch mal dein UML-Diagramm oder die eben die Interfaces der einzelnen Klassen.

Basti

[bobby]

Hi Basti,

mit UML kann ich leider derzeit nicht dienen, da ich bisher noch keinen schönen UML-Modeller unter Linux gefunden habe.

Aber die Klassengerüste sehen ungefähr so aus:

PHP-Code:

interface PF_Config_Interface
{
    public function __construct();
    public function load($filename, $index);
    public function get($item, $index);
    public function fetch($item, $index);
}

class PF_Config
{
    public function __construct()
    {

    }

    public function load($filename, $index)
    {

    }

    public function __call($method, $arguments)
    {

    }
}

class PF_Config_PHP implements PF_Config_Interface
{
    public function __construct()
    {

    }

    public function load($filename, $index)
    {

    }

    public function get($item, $index)
    {

    }

    public function fetch($item, $index)
    {

    }    
} 


Normalerweise lösen sich solche Problemchen immer während ich dusche - aber diesmal stehe ich anscheinend auf dem Schlauch.

bobby.

[ljungi]

Zitat von bobby

Hi Basti,

mit UML kann ich leider derzeit nicht dienen, da ich bisher noch keinen schönen UML-Modeller unter Linux gefunden habe.

Argouml ist toll

[kampfgnom]

Heiho
ich beschäftige mich zur zeit mit den Grundlagen von OOP
aber alle Tut's die ich so gefunden habe und als brauchbar für mich gewertet habe sind noch auf PHP4 basis das heißt es gibt noch keine public protected und so weiter sachen
folglich hab ich keine ahnung wie das funzt
hat jmd ein guten link dazu?

grüße
Gabriel

//Sorry für Offtopic Post aber ich dachte es passt einigermasen zum Thema und wollt kein eigenen Thread aufmachen!

[Artemis]

http://www.professionelle-softwareen...erste_auflage/

[xabbuh]

Zitat von ljungi

mit UML kann ich leider derzeit nicht dienen, da ich bisher noch keinen schönen UML-Modeller unter Linux gefunden habe.

Neben dem von ljungi erwähnten ArgoUML ist auch Umbrello sehr nett.

Gruß
Christian

[Basti]

…wozu __call()? Die Schnittstelle ist doch klar. Es gibt load(), get() und fetch() (wobei ich grad den Sinn noch nicht ganz blicke).

In jedem Fall würd ich die Parameter umdrehen, also erst index, dann item. Damit kannst du letzteren ggf. optional machen und so die ganze Config eines "index" auslesen.

Basti

[bobby]

Hi,

Zitat von xabbuh

Neben dem von ljungi erwähnten ArgoUML ist auch Umbrello sehr nett.

Gruß
Christian

Dank dir, aber ich habe derzeit keine KDE-Libraries installiert - werde es mir aber bald möglichst anschauen.

Zitat von Basti

…wozu __call()? Die Schnittstelle ist doch klar. Es gibt load(), get() und fetch() (wobei ich grad den Sinn noch nicht ganz blicke).

Der Unterschied zwischen get und fetch ist, dass get ein Objekt zurückliefert wenn das Item ein Array ist.

PHP-Code:

$config->get(0, 'database')->get('host'); 


Was ja hoffentlich mit den kommenden PHP Versionen "überflüssig" wird

PHP-Code:

$object->ich_liefere_ein_array('user')['name'] //Das war zumindest im Gespräch 


Zitat von Basti

In jedem Fall würd ich die Parameter umdrehen, also erst index, dann item. Damit kannst du letzteren ggf. optional machen und so die ganze Config eines "index" auslesen.

Basti

So einfach kann die Lösung sein - wieso ich da nicht selbst drauf gekommen bin .

Das Problem ist nun gelöst, aber wie definierst du eine Schnittstelle (die so wie in den oben genannten Bespielen funktioniert) ohne die Methoden zu kennnen? Da sehe ich nur den Weg über __call.

bobby

[Basti]

Du kennst die Methoden doch. Der Client der Config-Klasse hat die Methoden get() und fetch() zur Verfügung. Er weiß nichts davon, ob er gerade mit einer Klasse Config_PHP oder Config_CSV oder Config_XML arbeitet. In sofern ist es natürlich auch nicht möglich, aber auch nicht nötig, einzelne dieser Klassen mit Zusatzfunktionen auszustatten.

Welche Methode kennt denn Config nicht?

Basti

[bobby]

Hi Basti,

meine letzte Frage bezog sich nicht mehr auf die oben genannte Configklasse - es ging allgemein um eine Schnittstelle. Aber ich glaube da habe ich mir wieder ein Problem geschafften, wo es eigentlich nicht nötig wäre.

Danke an euch alle und vorallem Basti.

bobby

//edit: Gib es hier sowas wie "Gelöst" ?

[Jann Hendrik]

Zitat von bobby

//edit: Gib es hier sowas wie "Gelöst" ?

derzeit nicht.
Aber du kannst den thread-titel entsprechend ändern, wenn du das möchtest.

[WarrenFaith]

Den Threadtitel kann nur ein Mod/Admin ändern, nicht der Threadersteller
Der kann nur den Subtitle ändern.

[Basti]

BTW:
Kennt jemand eine gute Umsetzung für das prinzipielle Problem:
Ein Client baut ein Objekt von einer Klasse (z.B. Config oder Image), das Objekt entscheidet, welche konkrete Klasse die Datenquelle (etc.) handeln kann (Config_PHP, Image_Jpeg) und gibt eben dieses Objekt zurück. Alle diese konkreten Objekte implementieren eine Schnittstelle bzw. werden alle von einer gemeinsamen Basisklasse abgeleitet.

Mir fallen da nur zwei(einhalb) sinnige Lösungen ein:

1. Die Klasse Config/Image baut eine Instanz von Config_Csv, Image_Png etc. und behält diese als privates Objektattribut und gibt die Anfragen entsprechend weiter.

2. Es gibt eine Factory, die die jeweilige Klasse baut und zurückgibt.

2 1/2. Config bzw. Image verfügt über eine statische Factory-Methode und ist gleichzeitig Basisklasse für die konkreten Klassen.

Any patterns known?

Basti

[xabbuh]

Hallo Basti,

nach welchem Prinzip soll die Klasse den ermitteln, von welcher Klasse du ein Objekt benötigst? Und: Soll das Ganze als Singleton implementiert sein oder darf es mehr als ein Objekt je Klasse / Familie geben?

Gruß
Christian

[Basti]

Zitat von xabbuh

nach welchem Prinzip soll die Klasse den ermitteln, von welcher Klasse du ein Objekt benötigst?

Das spielt für die Fragestellung ja keine Rolle. Wichtig nur, dass der Client davon keine Ahnung hat (sonst könnte er ja das konkrete Objekt selber bauen).

Und: Soll das Ganze als Singleton implementiert sein oder darf es mehr als ein Objekt je Klasse / Familie geben?

Ist letztlich auch Wurscht.

Basti

[xabbuh]

Ich würde wohl den Weg über eine statische Methode getInstance() wählen, die in der Basisklasse definiert wird (also dein Punkt 2.5).

Punkt 1 halte insofern für wenig sinnvoll, da du so letztendlich die verwendete Schnittstelle doppelt implementieren musst nur um die Erzeugung des eigentlichen Objektes zu kapseln.

Gruß
Christian