Integration eines Pluginsystems in einer HMVC Struktur

Anyone · 18.12.2009, 21:45

Für mein bevorstehendes Projekt (bereits durch ein Pflichtenheft geplant) möchte ich die Vorzüge eines Pluginsystems nutzen. Als grundlegende Programmstruktur würde ich das HMVC pattern vorschlagen, da dieses ein sehr hohes Maß an Flexibilität und Erweiterbarkeit bietet.

Ich hatte bereits innerhalb von fünf Minuten ein triviales Pluginsystem entworfen, welches allerdings überhaupt nicht mit dem HMVC pattern in Verbindung gebracht werden kann:

PHP-Code:

  class PluginManager

{

    private $plugins = array();

    

    public function addPlugin(Plugable $plugin)

    {

        $this->plugins[] = $plugin;

    }

    

    public function loadPlugins()

    {

        foreach ($this->plugins as $plugin)

        {

            $plugin->execute();

        }

    }

}

 
interface Plugable

{

    public function execute();

}

 
class Testplugin1 implements Plugable

{

    public function execute()

    {

        echo "Ich bin Plugin1<br>";

    }

}

 
class Testplugin2 implements Plugable

{

    public function execute()

    {

        echo "Ich bin Plugin2";

    }

}

Ob die im Quellcode vorhandenen Plugins verwendet werden, wird durch eine kleine Datenbanktabelle (Plugin_ID, Plugin_Name, Plugin_IsActive) entschieden und dementsprechend werden die aktivierten Plugins initiiert und die 'execute()' Methode jedes aktiven Plugins ausgeführt. Wie ihr euch bereits denken könnt verwende ich dabei Templates (Achtung: Kein Templatesystem). Diese Templates können ähnlich einer Baumstruktur beliebig tief verschachtelt werden und jedes Template bildet genau eine MVC Triade.

Pluginsysteme bieten natürlich die Möglichkeit zur Installation / Deinstallation und Aktivierung / Deaktivierung und deren Plugins sollten möglichst unabhängig von einander sein (sonst wäre es ja kein Pluginsystem

).

Wie kann ein Pluginsystem realisiert werden, welches auf das HMVC pattern zugeschnitten ist? Ich bitte nur um Ansätze, keine Lösungen

dr.e. · 18.12.2009, 23:04

Hallo Anyone,

an dieser Stelle - denke ich - ist die Umsetzung von HMVC der Schlüssel. In einigen Threads hatten wir hier schon einige Male das Thema Plugin bzw. Schittstelle auf GUI-Ebene besprochen. Wenn du dir diese zu Gemüte führst, wirst du sehen, wie eine Schnittstelle diesbezüglich aussehen muss.

Da du dich bei HMVC auf GUI-Ebene befindest, wird die Schnittstelle auch eine solche sein. execute() hört sich zu sehr nach Business-Schicht an und ist die falsche Herangehensweise.

Anyone · 18.12.2009, 23:10

Zitat:

Zitat von dr.e.

Hallo Anyone,

an dieser Stelle - denke ich - ist die Umsetzung von HMVC der Schlüssel. In einigen Threads hatten wir hier schon einige Male das Thema Plugin bzw. Schittstelle auf GUI-Ebene besprochen. Wenn du dir diese zu Gemüte führst, wirst du sehen, wie eine Schnittstelle diesbezüglich aussehen muss.

Da du dich bei HMVC auf GUI-Ebene befindest, wird die Schnittstelle auch eine solche sein. execute() hört sich zu sehr nach Business-Schicht an und ist die falsche Herangehensweise.

Also ich habe mir vorhin ein Thema aus einem anderen Forum gesehen und deren Vorgehensweise scheint mir plausibler als meine. Dort werden entsprechende Pluginfunktionen registriert und einem übergeordneten Container zugewiesen.

PHP Plugin System - gulli:board

Würdest du das persönlich mit hooks lösen? Wie bleiben die Templates ob mit oder ohne Plugins trotzdem skalierbar?

Danke jedenfalls schonmal für dein Feedback.

PS: 'execute()' war erstmal nur ein ausgedachter Methodenname. Ist es übrigens normal ein paar Gehirnzellen bei solchen komplexeren Sachen zu verlieren?

xm22 · 19.12.2009, 13:53

Das habe ich seit kurzem auch bei mir implementiert - In 2 Formen: 1. Als Observer-Pattern, bei dem jede Klasse von einer abstrakten Klasse abgeleitet wird, die die Observer-Funktionen beinhaltet.
2. Eine Event-Klasse, bei der Events und dazugehörige Listener registirert werden können.

Damit kann ich so ziemlich alles abfeiern, was kommt..

Anyone · 19.12.2009, 15:31

Zitat:

Zitat von xm22

Das habe ich seit kurzem auch bei mir implementiert - In 2 Formen: 1. Als Observer-Pattern, bei dem jede Klasse von einer abstrakten Klasse abgeleitet wird, die die Observer-Funktionen beinhaltet.
2. Eine Event-Klasse, bei der Events und dazugehörige Listener registirert werden können.

Damit kann ich so ziemlich alles abfeiern, was kommt..

Könntest du das bitte, sofern ich nicht zuviel fordere, näher ausführen? Beide Formen sind mir natürlich ein Begriff, jedoch kann ich mir die Umsetzung im Moment nicht vorstellen.

Irgendwie habe ich das Gefühl, dass ich mich an etwas zu Großem gewagt habe, sowas ist meiner Meinung nach schon ein paar Ecken komplizierter als design patterns zu verstehen...

dr.e. · 20.12.2009, 20:16

Hi Anyone,

Zitat:

Zitat von Anyone

Also ich habe mir vorhin ein Thema aus einem anderen Forum gesehen und deren Vorgehensweise scheint mir plausibler als meine. Dort werden entsprechende Pluginfunktionen registriert und einem übergeordneten Container zugewiesen.

Der von dir gepostete Foren-Beitrag ist mir wenig aufschlussreich. Ich fand ihn etwas wirr. Wie ich schon sagte: der Schlüssel ist die HMVC-Implementierung. Stellt sie out-of-the-box eine definierte Umgebung für einen Sub-Knoten bereit, kannst du auf dieser Basis bereits ein einfaches Plugin aufsetzen.

Der Page-Controller des APF arbeitet genau nach diesen Vorgaben: der Subknoten des Baumes (ich nenne es mal Plugin) wird mit dem aktuellen Context, der aktuellen Sprache und den Informationen über sein Umfeld ausgestattet und in einen definierten Objekt-Lifecyle eingebunden. Als Subknoten weißt du genau, was du implementieren kannst und was wann ausgeführt wird. Mehr brauchst du IMHO erst mal nicht. Wenn es um die dynamische Einbindung von Plugins geht, so kann man sich Gedanken darüber machen, welche Informationen so ein Subknoten noch braucht oder wie man diesen "installiert". Gerade letzteres ist doch sehr einfach, wenn das Modul in einem eigenen Namespace liegt und es "einfach" per Namespace+Template importiert und ausgeführt wird. Wo, kann man ja in einer Konfiguration oder einer Datenbank speichern.

Zitat:

Würdest du das persönlich mit hooks lösen? Wie bleiben die Templates ob mit oder ohne Plugins trotzdem skalierbar?

Hooks finde ich an manchen Stellen durchaus sinnvoll, jedoch musst du beachten, dass dein Plugin Möglichkeiten hat, um auf Core-Funktionen zugreifen zu können. Aus diesem Grund finde ich den Namen "Hook" auch etwas schwierig, weil es mehr an einen "Hack" erinnert, denn an ein sauber gekapseltes Modul, dem Core-Funktionen über definierte Business-Komponenten zur Verfügung gestellt werden.
Aus diesem Grund würde ich versuchen, eine Schnittstelle einerseits so zu realsieren, dass sie in der GUI per HMVC eingeklinkt werden kann und ihm andererseits über definierte Business-Komponenten Core-Funktionen der eigentlichen Applikation (z.B. User-Management) zur Verfügung stehen.

Zitat:

PS: 'execute()' war erstmal nur ein ausgedachter Methodenname. Ist es übrigens normal ein paar Gehirnzellen bei solchen komplexeren Sachen zu verlieren?

Du glaubst garnicht wie viele Gehirnzellen bei so komplexen Themen aktiviert werden müssen...

Anyone · 20.12.2009, 20:31

Zitat:

Zitat von dr.e.

Hi Anyone,

Der von dir gepostete Foren-Beitrag ist mir wenig aufschlussreich. Ich fand ihn etwas wirr. Wie ich schon sagte: der Schlüssel ist die HMVC-Implementierung. Stellt sie out-of-the-box eine definierte Umgebung für einen Sub-Knoten bereit, kannst du auf dieser Basis bereits ein einfaches Plugin aufsetzen.

Der Page-Controller des APF arbeitet genau nach diesen Vorgaben: der Subknoten des Baumes (ich nenne es mal Plugin) wird mit dem aktuellen Context, der aktuellen Sprache und den Informationen über sein Umfeld ausgestattet und in einen definierten Objekt-Lifecyle eingebunden. Als Subknoten weißt du genau, was du implementieren kannst und was wann ausgeführt wird. Mehr brauchst du IMHO erst mal nicht. Wenn es um die dynamische Einbindung von Plugins geht, so kann man sich Gedanken darüber machen, welche Informationen so ein Subknoten noch braucht oder wie man diesen "installiert". Gerade letzteres ist doch sehr einfach, wenn das Modul in einem eigenen Namespace liegt und es "einfach" per Namespace+Template importiert und ausgeführt wird. Wo, kann man ja in einer Konfiguration oder einer Datenbank speichern.

Hooks finde ich an manchen Stellen durchaus sinnvoll, jedoch musst du beachten, dass dein Plugin Möglichkeiten hat, um auf Core-Funktionen zugreifen zu können. Aus diesem Grund finde ich den Namen "Hook" auch etwas schwierig, weil es mehr an einen "Hack" erinnert, denn an ein sauber gekapseltes Modul, dem Core-Funktionen über definierte Business-Komponenten zur Verfügung gestellt werden.
Aus diesem Grund würde ich versuchen, eine Schnittstelle einerseits so zu realsieren, dass sie in der GUI per HMVC eingeklinkt werden kann und ihm andererseits über definierte Business-Komponenten Core-Funktionen der eigentlichen Applikation (z.B. User-Management) zur Verfügung stehen.

Du glaubst garnicht wie viele Gehirnzellen bei so komplexen Themen aktiviert werden müssen...

Vielen Dank für deinen aufschlussreichen Beitrag. Es ist wirklich manchmal gut, wenn man sich darüber im Klaren wird, was und wann etwas in Programmen getan werden muss.

PS: Darf ich im Forum, vielleicht in einem anderen Thema, meine Grundstruktur des Klassendiagramms vorstellen und auf Feedback hoffen?

Danke dir und schönen vierten Advent und frohe Weihnachten noch.

dr.e. · 20.12.2009, 21:42

Hi Anyone,

stell deine Architektur doch hier im Thread vor. Gehört schließlich zum Thema.

Anyone · 21.12.2009, 00:13

Dankeschön, dennoch wird mein Klassendiagramm sowieso das schlechteste sein, was ihr jemals zu Gesicht bekommen habt.

http://img687.imageshack.us/i/klassendiagramm.png/

PS: Das Pluginsystem habe ich erstmal bewusst außenvor gelassen. Es werden auch noch Viewhelper integriert werden.

xm22 · 21.12.2009, 09:21

Front-Controller und Action-Controller erben von der selben Klasse? Ich weiß nicht - Die haben völlig verschiedene Aufgaben..

Für was sind die Stacks gut?

Zu der Event-Sache:

Die Event-Klasse ist sehr einfach aufgebaut:

PHP-Code:

  <?php
    class Core_Event {
        
        protected static $events = null;
        
        public static function register($event, $callback) {
            self::$events[$event][] = $callback;
        }
        
        public static function remove($event, $processor = null) {
            if ($processor === null) {
                unset(self::$events[$event]);
            } else if ($key = in_array($processor, self::$events[$event])) {
                unset(self::$events[$event][$key]);
            }
        }
        
        public static function post($event, $sender) {
            $out = array();
            $args = func_get_args();
            if (isset(self::$events[$event]) && is_array(self::$events[$event])) {
                
                foreach (self::$events[$event] as $callback) {
                    $out[] = call_user_func_array($callback, $args);
                }
            }
            
            return $out;
        }
    }

Einen Handler/Listener zu registrieren, ist ebenfalls entsprechend einfach:

PHP-Code:

  Core_Event::register('frontController.preRouteDispatch', array($object, 'respond'));

Das Posten eines Events ebenso:

PHP-Code:

  Core_Event::post(
                'frontController.preRouteDispatch',
                $this,
                $this->request,
                $this->response,
                $this->config,
                $this->router
            );

Dr. E. wird jetzt bemängeln

, dass jeder Listener den Kontext des Events kennen muss und die Argumente, die mit dem Event übergeben werden. Ich halte das jedoch für angemessen.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Struktur im Newssystem	tinchen	PHP Tipps 2007	4	10.07.2007 21:20
wer weiß wie man so ein struktur schreibt??		HTML, Usability und Barrierefreiheit	1	30.08.2004 10:50

18.12.2009, 21:45
Anyone Benutzer Registriert seit: 07.08.2009 Beiträge: 94 PHP-Kenntnisse: Anfänger	Integration eines Pluginsystems in einer HMVC Struktur Für mein bevorstehendes Projekt (bereits durch ein Pflichtenheft geplant) möchte ich die Vorzüge eines Pluginsystems nutzen. Als grundlegende Programmstruktur würde ich das HMVC pattern vorschlagen, da dieses ein sehr hohes Maß an Flexibilität und Erweiterbarkeit bietet. Ich hatte bereits innerhalb von fünf Minuten ein triviales Pluginsystem entworfen, welches allerdings überhaupt nicht mit dem HMVC pattern in Verbindung gebracht werden kann: PHP-Code: class PluginManager { private $plugins = array(); public function addPlugin(Plugable $plugin) { $this->plugins[] = $plugin; } public function loadPlugins() { foreach ($this->plugins as $plugin) { $plugin->execute(); } } } interface Plugable { public function execute(); } class Testplugin1 implements Plugable { public function execute() { echo "Ich bin Plugin1<br>"; } } class Testplugin2 implements Plugable { public function execute() { echo "Ich bin Plugin2"; } } Ob die im Quellcode vorhandenen Plugins verwendet werden, wird durch eine kleine Datenbanktabelle (Plugin_ID, Plugin_Name, Plugin_IsActive) entschieden und dementsprechend werden die aktivierten Plugins initiiert und die 'execute()' Methode jedes aktiven Plugins ausgeführt. Wie ihr euch bereits denken könnt verwende ich dabei Templates (Achtung: Kein Templatesystem). Diese Templates können ähnlich einer Baumstruktur beliebig tief verschachtelt werden und jedes Template bildet genau eine MVC Triade. Pluginsysteme bieten natürlich die Möglichkeit zur Installation / Deinstallation und Aktivierung / Deaktivierung und deren Plugins sollten möglichst unabhängig von einander sein (sonst wäre es ja kein Pluginsystem ). Wie kann ein Pluginsystem realisiert werden, welches auf das HMVC pattern zugeschnitten ist? Ich bitte nur um Ansätze, keine Lösungen


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

18.12.2009, 23:04
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Hallo Anyone, an dieser Stelle - denke ich - ist die Umsetzung von HMVC der Schlüssel. In einigen Threads hatten wir hier schon einige Male das Thema Plugin bzw. Schittstelle auf GUI-Ebene besprochen. Wenn du dir diese zu Gemüte führst, wirst du sehen, wie eine Schnittstelle diesbezüglich aussehen muss. Da du dich bei HMVC auf GUI-Ebene befindest, wird die Schnittstelle auch eine solche sein. execute() hört sich zu sehr nach Business-Schicht an und ist die falsche Herangehensweise. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

19.12.2009, 13:53
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.169 PHP-Kenntnisse: Fortgeschritten	Das habe ich seit kurzem auch bei mir implementiert - In 2 Formen: 1. Als Observer-Pattern, bei dem jede Klasse von einer abstrakten Klasse abgeleitet wird, die die Observer-Funktionen beinhaltet. 2. Eine Event-Klasse, bei der Events und dazugehörige Listener registirert werden können. Damit kann ich so ziemlich alles abfeiern, was kommt..

20.12.2009, 21:42
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Hi Anyone, stell deine Architektur doch hier im Thread vor. Gehört schließlich zum Thema. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

21.12.2009, 00:13
Anyone Benutzer Registriert seit: 07.08.2009 Beiträge: 94 PHP-Kenntnisse: Anfänger	Dankeschön, dennoch wird mein Klassendiagramm sowieso das schlechteste sein, was ihr jemals zu Gesicht bekommen habt. http://img687.imageshack.us/i/klassendiagramm.png/ PS: Das Pluginsystem habe ich erstmal bewusst außenvor gelassen. Es werden auch noch Viewhelper integriert werden. Geändert von Anyone (21.12.2009 um 00:27 Uhr).

21.12.2009, 09:21
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.169 PHP-Kenntnisse: Fortgeschritten	Front-Controller und Action-Controller erben von der selben Klasse? Ich weiß nicht - Die haben völlig verschiedene Aufgaben.. Für was sind die Stacks gut? Zu der Event-Sache: Die Event-Klasse ist sehr einfach aufgebaut: PHP-Code: <?php class Core_Event { protected static $events = null; public static function register($event, $callback) { self::$events[$event][] = $callback; } public static function remove($event, $processor = null) { if ($processor === null) { unset(self::$events[$event]); } else if ($key = in_array($processor, self::$events[$event])) { unset(self::$events[$event][$key]); } } public static function post($event, $sender) { $out = array(); $args = func_get_args(); if (isset(self::$events[$event]) && is_array(self::$events[$event])) { foreach (self::$events[$event] as $callback) { $out[] = call_user_func_array($callback, $args); } } return $out; } } Einen Handler/Listener zu registrieren, ist ebenfalls entsprechend einfach: PHP-Code: `Core_Event::register('frontController.preRouteDispatch', array($object, 'respond'));` Das Posten eines Events ebenso: PHP-Code: `Core_Event::post( 'frontController.preRouteDispatch', $this, $this->request, $this->response, $this->config, $this->router );` Dr. E. wird jetzt bemängeln , dass jeder Listener den Kontext des Events kennen muss und die Argumente, die mit dem Event übergeben werden. Ich halte das jedoch für angemessen.