[WarrenFaith]

Aloah.
Stellen wir uns mal vor, jeder von euch hat ein eigenes Framework gebastelt und möchte nun Module dazu entwickeln. Wir würdet ihr die Einbindung realisieren? Denn ein Modul ist ja nur optional...

Ich würde erstmal dem Framework ne index.php und jedem Modul nen eigenen Ordner mit eigener Struktur und eigener index.php verpassen.
Nun gehts um das dynamische einbinden von Klassen via __autoload(). Soll ich die __autoload() des Frameworks von beginn an so programmieren, dass er nach Modulen sucht und auch dort schaut, ob es die Klassen gibt? Oder wäre es besser, jedem Modul eine eigene __autoload() zu verpassen, die auch auf das Framework zugreifen kann?

Eine andere Idee wäre vielleicht eine registry.php in der alle Module und deren Klassen hinterlegt sind und die __autoload() arbeitet diese dann durch. Wäre so ne Art Index auf Dateiebene. Problem wäre die aktualisierbarkeit und die verlorengegangene Dynamik die ich mit __autoload() ja waren wollte. Also eher bäh die Idee.

Wir habt ihr das gemacht? Wie würdet ihr das machen?

Danke

[Chr!s]

Wie sehen die Module denn aus?
Sind diese Module nur einzelne Dateien, oder manchmal wirklich ganze, quasi kleinere Frameworks? Wenn das nur einzelne Dateien sind, würd ich einfach einen neuen Ordner anlegen, diesen mit glob() auslesen (wobei ich irgendwo mal gelesen hab, dass die opendir()-Variante sogar etwas schneller sein soll?). In dem Fall müsstest du ja nicht so viel suchen, ein Ordner durchsuchen geht mit PHP wohl ziemlich rasch. So könntest du die einzelnen Module nachladen, und zwar dynamisch.

Die andere Ar, über eine registry.php wär zwar auch denkbar, ist meiner Meinung nach aber dann ja nicht mehr so dynamisch - dann könntest du die auch gleich per *_once einbinden.

Ich persönlich habe das wie in oben beschrieben gelöst (1 Ordner)

[Ben]

Hm, das ist so eine Frage, über die ich mir schon 34mal beim Spazierengehen am Rhein Gedanken gemacht habe.

Generell würde ich sagen, dass es die Möglichkeit geben sollte Module online "hinzuzufügen".
Heißt also, dass man ein Modul zunächst einmal in den Ordner "modules"/"plugins"/was auch immer kopiert.

./modules
 |- ./my_module
 |- ..

Jut. Dann würde ich in einer Datenbanktabelle abspeichern, welche Module gerade aktiv sind und welche deaktiviert.
So kann man vermeiden, dass Leute einen Blog nutzen, auch wenn kein Link zum Blog auf der Seite existiert, sondern die Leute über einen Bookmark da hingelangt sind.

Jut.
Bisher gut um die eigentliche Frage gedrückt.
Eventuell sollte man von Beginn an standardmäßig den include_path um den Pfad zum "modules"-Ordner erweitern.

Eine Klasse, die nun z.B. einen Blog darstellt läge also z.B. hier

./modules/Blog/Modul.php

Die Klasse würde dann Blog_Modul heißen. Nagelt mich nicht auf Namen fest! Ist halt nur ein möglicher Weg.

Gut. Wenn man davon ausgeht, dass man im System eine zentrale Stelle hat, in der alle Pfäden zusammenlaufen, so müsste ja dort irgendwie jetzt eine Änderungen vorgenommen werden.
Vielleicht nicht korrekt ausgedrückt ... es müsste dort nun irgendwie dynamisch festgelegt werden, dass, wenn ein bestimmter Link angeklickt, also ein spezieller URL aufgerufen wird, ein Modul gestartet werden soll.

Wie das geht ... joaaa ... .
So ganz weiß ich das auch nicht.

Möglich wäre z.B. die Arbeit mit einem include_once(). Man legt also im ACP fest, bei welcher URL das Modul aufgerufen werden soll (ich gehe jetzt mal davon aus, dass das ACP das dynamisch kann. Ist das nicht der Fall, so wird halt einfach ein fixer URL vorgegeben!).

Sagen wir also, dass der Blog aufgerufen werden soll, wenn www.example.com/blog/ in der Adresszeile steht.

In der "Zentrale" wird nun überprüft, ob der URL einem URL entspricht, der in der Datenbank hinterlegt wurde. Ist das der Fall, wird die damit verknüpfte Aktion ausgeführt: in unserem Fall also ein Modulaufruf.

Nun wollen wir aber ja sicherstellen, dass in der "Zentrale" kein Code geändert werden muss ... somit erweitern wir ihn einfach mit einfachsten Mitteln.
Setzt man regeln voraus, an die man sich halten muss, wenn man Module schreibt, so ist das sicherlich eine wirksame und einfache Möglichkeit eine Anwendung zu erweitern.

Wir binden einfach eine "blog_actions.php" mittels include_once() in einer Methode des "Controllers" (so nenn ich das jetzt mal) ein und erweitern somit den dort vorhandenen Code. Es ist somit sogar möglich auf Klassenvariablen, z.B. ein Konfigurations- oder Datenbankverbindungsobjekt zuzugreifen!

Das sehe ich persönlich an dieser Methode als sehr positiv an.
Selbstverständlich muss jedes Plugin bzw. die einzubindende Datei so implementiert sein, dass keine Fehler auftreten.
Dazu müssen dann eben strikte Regeln existieren.

Wie gesagt .. ich habe da schon lange drüber nachgedacht und noch nicht wirklich die perfekte Lösung gefunden, obwohl ich die hier schon ganz nett finde ..

Ich hör mir aber auch gerne andere Möglichkeiten an.
Bei Fragen zu meiner Methode .. immer her damit.

Grüße, Ben.

[WarrenFaith]

Also die größe der Module muss definitiv nach oben offen sein. Es sind also nicht nur ein oder zwei Dateien sondern es können eigene Klassenstrukturen mit eigenen Templates und und und werden.

Ich glaube es macht Sinn, wenn ich einem Modul eine eigene index.php verpasse und dort das Framework einbinde und damit arbeite.
Problematisch wirds dann sicherlich wenn ein Modul auch ein anderes Benutzen könnte (optional) bzw braucht. Z.b. ein Adressverwaltung welches auch Geburtstage im Kalendermodul erzeugen kann, wenn Kalendermodul existiert und freigegeben ist.

Die Lösung mit der Datenbank wäre in meinen augen ja die gleiche Lösung wie die registry.php. Vorteil bei der registry wäre, dass ich nicht erst eine DB-Verbindung/DB-Klasse einbinden muss um zu wissen was ich hab und kann...

Horde hat das so gelöst:

PHP-Code:

<?php
/**
 * registry.php -- Horde application registry.
 *
 * $Horde: horde/config/registry.php.dist,v 1.255.2.14 2006/03/13 18:13:04 jan Exp $
 *
 * This configuration file is used by Horde to determine which Horde
 * applications are installed and where, as well as how they interact.
 *
 * Application registry
 * --------------------
 * The following settings register installed Horde applications.
 * By default, Horde assumes that the application directories live
 * inside the horde directory.
 *
 * Attribute     Type     Description
 * ---------     ----     -----------
 * fileroot      string   The base filesystem path for the module's files.
 * webroot       string   The base URI for the module.
 * jsuri         string   The base URI for static javascript files.
 * jsfs          string   The base filesystem path for static javascript files.
 * themesuri     string   The base URI for the themes. This can be used to
 *                        serve all icons and style sheets from a separate
 *                        server.
 * themesfs      string   The base file system directory for the themes.
 * icon          string   The URI for an icon to show in menus for the module.
 *                        Setting this will override the default theme-based
 *                        logic in the code.
 * name          string   The name used in menus and descriptions for a module
 * status        string   'inactive', 'hidden', 'notoolbar', 'heading',
 *                        'block', 'admin', or 'active'.
 * provides      string   Service types the module provides.
 * initial_page  string   The initial (default) page (filename) for the module.
 * templates     string   The filesystem path to the templates directory.
 * menu_parent   string   The name of the 'heading' group that this app should
 *                        show up under.
 * target        string   The (optional) target frame for the link.
 * url           string   The (optional) URL of 'heading' entries.
 */

// We try to automatically determine the proper webroot for Horde
// here. This still assumes that applications live under horde/. If
// this results in incorrect results for you, simply change the two
// uses of the $webroot variable in the 'horde' stanza below.
//
// Note for Windows users: the below assumes that your PHP_SELF
// variable uses forward slashes. If it does not, you'll have to tweak
// this.
if (isset($_SERVER['PHP_SELF'])) {
    $webroot = preg_split(';/;', $_SERVER['PHP_SELF'], 2, PREG_SPLIT_NO_EMPTY);
    $webroot = strstr(dirname(__FILE__), '/' . array_shift($webroot));
    if ($webroot !== false) {
        $webroot = preg_replace(';/config$;', '', $webroot);
    } elseif ($webroot === false) {
        $webroot = '';
    } else {
        $webroot = '/horde';
    }
} else {
    $webroot = '/horde';
}

$this->applications['horde'] = array(
    'fileroot' => dirname(__FILE__) . '/..',
    'webroot' => $webroot,
    'initial_page' => 'login.php',
    'name' => _("Horde"),
    'status' => 'active',
    'templates' => dirname(__FILE__) . '/../templates',
    'provides' => 'horde'
);
?>

Ich hab mir das ganze auch mal überlegt und ich bin zu folgender Lösung gekommen:

Im Framework bestehen die Klassen nur aus Buchstaben zB MySuperClass
Die Module werden aber Module_Asdf benannt.

Folglich verwende ich für das Framework autoload Arrays und bei den Modulen wird einfach _ durch / ersetzt.

Damit habe ich sinnvolle Namen im Framework zB anstatt Filter_Input InputFilter und bei den Modulen habe ich Module_Name_IncludeClass.

Damit kann ich auch online einfach Module hinzufügen.

Außerdem hat jedes Modul ein XML File wo eine individuelle Konfiguration gemacht werden kann und das Modul näher beschrieben wird.

Die Liste der Module wird automatisch erzeugt. Ich lese einfach alle XML Files aus und führe den Titel, die Version, den Autor und die Beschreibung zu einem File zusammen (als Cache sozusagen).

Objekte werden automatisch gecached.

-- Jay