[Erledigt] HMVC - mein Konzept zur Umsetzung

mbunge · 21.01.2011, 16:33

Werte PHPler,

im Zuge einer Lightweight-Framework-Eigenentwicklung, möchte ich das aktuelle MVC Pattern um das HMVC (Layerd MVC) erweitern.

Standart mäßig wird beim Start einer Application der Frontcontroller geladen. Die Routerklasse sagt dann welcher ActionController geladen werden soll. Im ActionController soll man die Möglichkeit haben andere Controller reinzuladen. Den ActionControllern werden die Request und Response-Objekte übergeben, um sicher zu gehen ob es sich wirklich um Request / Reponse-Objekte handelt wird Type-Hinting verwendet.

Request und Responseobjekte sind als Singleton realisiert.

Meine Idee war jetzt einen LayerController (eine Art FrontController zu verwenden). Diesem LayerController kann man 2 Parameter übergeben. Parameter 1 entspricht dem Controllernamen. der ActionControllername kann als der Klassennamen und / oder Pfad übergeben werden. Als 2 Parameter soll ein alternatives Array für die Übergabe von optionalen Werten für das Request / Response Objekt sein.

Der LayerController lädt den aktuellen Request / Response automatisch ein. Und erweitert Req. Resp. ggf um werte bzw. überschreibt diese. Zudem habe ich überlegt, dass die Manipulation von Header, also die Setter, innerhalb eines Layer nicht möglich sein soll, da diese bereits im Parent-ActionController gesetzt werden.

Zusätzlich gibt es eine Methode die es Ermöglicht den Zugriff des LayerController auf einen ActionController zu verhindern, wenn dieser kein Layer sein soll / darf.

Hier ein Beispiel innherhalb eines ActionController:

PHP-Code:

  <?php
/**
 * This file is part of the SXPHP-Framework.
 * (c) 2011 Marco Bunge
 *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 * @author Marco Bunge
 * @copyright Marco Bunge 2011
 * @category SX
 * 
 */
 
 /**
* 
* Application_Controllers_Default class.
* 
* @package Application_Controller
* 
*/

class Application_Controller_Action_Index
extends SX_Core_Controllers_Action
{
    public function __construct(){
        parent::__construct();
        
        //Dieser Actioncontroller soll nicht as Layer verwendet werden
        $this->disableLayering(__CLASS__);
    }

    public function index(){
        
        $customRequest = new stdClass();
        //HTTP-Get Vars manipulieren
        $customRequest->getVars = array('hello' => 'world', 'send' => true);
        
        $layerLoginForm = $this->getLayer('forms/auth/loginWidget', array('request' => $customRequest));
        
        unset($customRequest);
        $customRequest = new stdClass();
        
        //HTTP-Get Vars manipulieren
        $customRequest->getVars = array('hello' => 'world', 'send' => true);
        
        //ActionController als Layer laden
        $layerLatestBoardEntries = $this->getLayer('forum/latestEntriesWidget', array('request' => $customRequest));
        
        //Variable-Collection des latestEntriesWidget ActionControllers holen
        $boardVars = $layerLatestBoardEntries->getAssignedVarsObject();
        
        //Die gesamte Ausgabe des LoginFormWirdget-ActionControllers in eine Variable speichern
        $this->assignVar('loginForm', $layerLoginForm->dispatch());
        
        //eparate Variablen zuweisen
        $this->assignVar('latestBoardEntriesTitle', $boardVars->title);
        $this->assignVar('latestBoardEntriesCreationDate', $boardVars->creationDate);
        
        //View anzeigen
        $this->htmlView('startseite', $data);
    }
        
}

Was haltet ihr von dem Konzept?
Was würdet ihr andersmachen und warum?
Wo seht ihr Schwierigkeiten?

Für Kritik bin ich offen

MfG
Marco

G.Schuster · 21.01.2011, 23:22

Da ich schon auf dem Weg Richtung Couch bin nur eins kurz:

Zitat:

Zitat von mbunge

PHP-Code:

      public function __construct(){
        parent::__construct();
        
        //Dieser Actioncontroller soll nicht as Layer verwendet werden
        $this->disableLayering(__CLASS__);
    }

Spar' dir den Konstruktor, nutze eine separate (abstrakte) init()-Methode, dann kann man auch das parent::__consturct() nicht mal aus Versehen vergessen.

dr.e. · 23.01.2011, 11:21

Hallo Marco,

hast du dir die bereits zu diesem Thema existierenden Beiträge durchgelesen? Es gibt etwa eine Hand von Themen, in denen der Nachteil von Controller-basierten HMVC-Ansätzen diskutiert wird.

Zitat:

Was haltet ihr von dem Konzept?

Es ist für mich nicht nachzuvollziehen, was daran HMVC ist und wie es sich zu MVC unterscheidet. Das Boostrapping und Routing unterscheidet sich nach deiner Beschreibung nicht von MVC - was nicht funktionieren kann - und es gibt dedizierte Strukturen ("Pfad"). Letzteres wiederspricht HMVC zwar nicht vollständig, ist aber eine Einschränkung, die ich mir bei einer Flexibilisierung von MVC nicht wieder ienkaufen will.

Zitat:

Wo seht ihr Schwierigkeiten?

Meiner Erfahrung nach lässt sich HMVC nur dann generisch (ohne direkte Abhängigkeiten von Komponenten/Ebenen/Elementen) implementieren, wenn die Kopplung nicht in einem Controller, nicht in einem Front-Controller und nicht in einem Router stattfindet. Viele PHP-Frameworks schnüren MVC in ein starres Konstrukt, bei dem das Routing genau auf einen Controller und einen View leitet. Übernimmst du das auch für HMVC in dem es mehrere Controller und mehrere Views geben muss, schaffst du dir ein Problem, das du nur mit Workarounds lösen kannst, wie es View-Helper bei MVC sind um eine Wiederverwendbarkeit zu schaffen. Das alles sind aber Krücken und kein Mehrwert.

Zitat:

Was würdet ihr andersmachen und warum?

Die Kopplung sollte von einer Komponente ausserhalb deines Controllers und deines Views geschaffen werden (inversion of control). Damit lässt sich die harte Kopplung herauslösen und die einzelnen Ebenen können beliebig aufgebaut sein - sogar von einem Request zum nächsten. Weiter würde ich bei HMVC auf ein starres Routing verzichten, das bringt zum Einen nur weitere Einschränkungen mit sich und zum anderen wirst du dadurch das volle Potential von HMVC nie erreichen.

Für mehr Material suche dir bitte mal die Beiträge zum Thema "HMVC" aus dem Forum hier, darin kannst du noch einige Aspekte mehr beziehen.

mbunge · 25.01.2011, 07:44

Hi,

erst einmal vielen Dank für eure Antworten.

@ G. Schuster: Danke für den Tipp. Darüber werde ich meine Gedanken schweifen lassen, wenn ich meine Konzept zu HMVC (PAC) abschließend fertig gestellt habe. Ich nehme an die init-Methode wird als "Constructor-Ersatz" aufgerufen.

@ Dr. e.: Generell danke für die Erleuterung. Die Froum-SuFu hat mir ein hilfreiche Themen ausgespuckt und ich werde mich mal in das PAC-Pattern reinarbeiten.

Allgemein bin ich am überlegen, ob ich aktuell wirklich eine hierarchische Struktur in meinem Framework brauche. Es gibt ja auch die Möglichkeit Subcontroller / Widgetcontroller zu nutzen. Weitere Gedanken habe ich mir dazu nicht gemacht. Vorerst werde ich weitere Informationen sammeln und eine Pro / Kontr-Liste aufstellen und dann einen Nutzungsvergleich meines Frameworks aufstellen.

Wenn ich eine Lösung gefunden habe werde ich Sie euch im Detail mitteilen.

Edit: ein erster Ansatz:

1. Der ActionController (per Routing definiert) wird aufgerufen. Sofern keine Methode (ebefalls im Router definiert) angegeben wurde wird index() aufgerufen. (Wie vorher)
2. Über den LayerController kann man weitere ActionController laden. Im Layercontroller werden die Request und das ResponseObject an den neuen ActionController übergeben (neu: Es kann nichts mehr manipuliert werden, der Router hat keinen Effekt). Es wird das komplette Objekt zurückgegeben. ActionMethoden bzw. View-Variablen aus den ActionMethoden können an Variablen im Haupkontroller übergeben werden.

Ich sehe da aber immer noch Probleme.

Zum einen ist dieses Vorgehen unflexibel, da für jede ActionMethode das Layer erneut eingebunden werden muss. Dies kann im Konstruktor geschehen, jedoch wirken sich änderungen auf jede ActionMethode im ActionController aus.

MfG
Marco

mbunge · 04.02.2011, 15:51

Hallo PHPler,

Nach langem überlegen, konzipieren, Papier zerknüllen und neu-denken bin ich zum Schluss gekommen, dass beste Lösung, ein HMVC-Pattern zu etablieren, die einbindung über Views ist.

Heute möchte ich keine PHP-Beispielcode präsentieren, eher möchte ich euch erzählen welche Ideen, (die nichts mit HMVC zu tun haben) mir noch gekommen sind.

Bei mienen Überlegungen ist immer der Aspekt der Wiederverwenbarkeit ins auge gesprungen, dies war bei meinem Eingangspost nicht gegeben. Darum beruhen meine Nachfolgenden Ideen auf die Wiederverwendbarkeit von Quellcode.

1. HMVC - meine Gedanken.

Einleitung:

Wie es beim APF überlich ist werde ich die HMVC-Implementierung unteranderem per View einbinden. Die geschieht über einen Event-Handler, der es erlaubt neben einer MVC-Triade auch ausgelagerte Views oder Layer einzuladen.

Eventbasiertes einladen von Komponenten (besseres Wort...?)

MVC-Triade

Eine MVC-Triade besteht aus dem MVC-Pattern. Dafür wird eine gesonderter Request erstellt und ggf. mit einem Response zurückgegeben. Der response kann dann per print, echo etc. ausgegeben werden.

ausgelagerte Views

Durch das laden einer Ausgalagerten view kann die Weiderverwendbarkeit erhöht werden. sinn macht dies wenn man Views nur für bestimme Einsätze laden möchte und dieser View keine Logik benötigt. Bspw. Header, Footer ohne Logik.

Layer

Ein Layer besteht aus einem assioativen Array, in dem wiederum Views, Layer und MVC-Triaden per Request angesteuert werden können. Das Array kann n-fach geschatelt werden. Ein Layer hat folgende Form:

PHP-Code:

  <?php

//Layerarray

array(

    'request' => array(

        /* 

         * action:action_controller/action

         * view:view_name

         * layer:layer_name

         */

        'route' => 'key:value',

        

        /*

         * Request-Method

         */

        'post' => array(

            'user_id' => '1',

            'anotherparam' => 'hello'

        )

    ),

    'response' => array(

        'output_type' => 'xhtml'

    ),

    

    /*

     * Child of current Layer

     */

    

    'child' => array()

)

?>

Das Array wird Rekursiv abgearbeitet und Layer-Elemente werden während der Abarbeitung ausgeführt.

2. ausggelagerte Action-Methode im Action-Controller

Actions sind Methoden in einer Action-Controller-Klasse. Hat man jetzt n Controller mit der selben Action, die ein und die selbe Logik ausführt, ist auf Grund der Wiederverwendbarkeit nur sinnvoll, die Action als Klasse auszulagern. Für die Action-Klasse wird das Command-Pattern genutzt. Nun hat man einen Action-Command

Im action-Controller kann man mit den Action-Command per __call aufrufen. __call sollte sinnigerweise in der Elternklasse definiert werden.

Soweit mit meinen Gedanken. Kritik, Weitere Ideen Verbesserungen sind erwünscht!

MfG
Marco

dr.e. · 04.02.2011, 17:13

Zitat:

Wie es beim APF überlich ist werde ich die HMVC-Implementierung unteranderem per View einbinden. Die geschieht über einen Event-Handler, der es erlaubt neben einer MVC-Triade auch ausgelagerte Views oder Layer einzuladen.

Provokant gefragt: warum nutzt du das APF denn nicht, wenn es bereits alle deine Anforderungen (insbesondere auch das Thema Front-Controller-Actions) erfüllt?

mbunge · 04.02.2011, 19:17

Ich möchte einfach die Zusammenhänge in einem Framework verstehen. Und weil Software im Grunde genommen auf einem minimalen Framework aufbauen, öchte ich soetwas nachbauen. Zu dem hilft es mir bei Entwicklung bei uns im Unternehmen

Lernen, Lernen, Lernen.

MfG

dr.e. · 04.02.2011, 20:49

Hallo mbunge,

nachdem ich heute Nachmittag nicht viel Zeit hatte zu antworten, möchte ich noch ein paar Worte zu deinen Posts sagen.

Zitat:

Nach langem überlegen, konzipieren, Papier zerknüllen und neu-denken bin ich zum Schluss gekommen, dass beste Lösung, ein HMVC-Pattern zu etablieren, die einbindung über Views ist.

Ich finde es schön, dass der vom APF schon seit langem vertretene Ansatz auch durch Überlegung weiterer bestätigt wird. In der Tat ist es so, dass die Struktur der GUI eine Möglichkeit darstellt Elemente oder Module sehr elegant basierend auf einer allgemeingültigen Schnittstelle zu koppeln.
Meiner Ansicht nach bietet die GUI den größtmöglichen Schnittpunkt eines Moduls oder Teils einer Software mit ihrer Gesamtheit. Business-Logik und Datenhaltung unterscheiden sich zumeist doch zu weit als dass dort eine so unkomplizierte Kopplung möglich ist.

Zitat:

MVC-Triade

Eine MVC-Triade besteht aus dem MVC-Pattern. Dafür wird eine gesonderter Request erstellt und ggf. mit einem Response zurückgegeben. Der response kann dann per print, echo etc. ausgegeben werden.

Gesonderte Requests halte ich für problematisch, da du für eine Webseite bestehend aus 3 Teilen auf dem Webserver dann 4 Requests stellst und auswerten musst. Schneller als alles in einem Request zu bearbeiten wird das sicher nicht sein und einfacher von der Implementierung auch nicht. Was spricht gegen die Verarbeitung eines Requests in einem Request (wie es auch das HTTP-Protokoll beschreibt)?

Zitat:

ausgelagerte Views

Durch das laden einer Ausgalagerten view kann die Wiederverwendbarkeit erhöht werden. sinn macht dies wenn man Views nur für bestimme Einsätze laden möchte und dieser View keine Logik benötigt. Bspw. Header, Footer ohne Logik.

Warum unterscheidest du zwischen einem "ausgelagerten View" und einem "View"? Das ist doch technisch identisch. Für mich also ebenso unnötig wie im Kontext des HMVC-Pattern von einem Layout zu sprechen. HMVC beschreibt ein mehrschichtiges MVC-Modell, das eben aus mehreren dieser Einheiten besteht. Wenn du die erste Ebene "Layout" nennen möchtest ist das legal, technisch ist es nichts weiter als die erste Ebene eines HMVC-Baumes.

Zitat:

Layer

Ein Layer besteht aus einem assioativen Array, in dem wiederum Views, Layer und MVC-Triaden per Request angesteuert werden können. Das Array kann n-fach geschatelt werden. Ein Layer hat folgende Form:

Das halte ich für einen definitiven Fehler. Die Diskussion hierzu hatten wir im Forum bereits beim Thema PAC und einigen weiteren HMVC-Diskussionen geführt. Das was du darstellst ist damit kein HMVC sondern nur ein Workaround um aus MVC irgendwie HMVC zu generieren ohne das wirklich sauber zu implementieren. Wenn du wirklich HMVC möchtest, muss das unabhängig von irgendwelchen starren Konfigurations-Strukturen möglich sein. Eine tiefere Ebene des Baumes bestimmt sich dann eben durch die Inhalte der übergeordneten Ebene.

Zitat:

2. ausggelagerte Action-Methode im Action-Controller

Actions sind Methoden in einer Action-Controller-Klasse. Hat man jetzt n Controller mit der selben Action, die ein und die selbe Logik ausführt, ist auf Grund der Wiederverwendbarkeit nur sinnvoll, die Action als Klasse auszulagern. Für die Action-Klasse wird das Command-Pattern genutzt. Nun hat man einen Action-Command

Im action-Controller kann man mit den Action-Command per __call aufrufen. __call sollte sinnigerweise in der Elternklasse definiert werden.

Was ist dann der Unterschied zwischen dem MVC- und dem Action-Controller? In deinem Satz sind viele Pattern versteckt, sinnvoll zusammen passen diese für mich mit der obigen Beschreibung konzeptionell nicht.

Noch ein Wort zu deinem letzten Post:

Zitat:

Ich möchte einfach die Zusammenhänge in einem Framework verstehen. Und weil Software im Grunde genommen auf einem minimalen Framework aufbauen, öchte ich soetwas nachbauen.

Ich würde dir gerne beim "Verstehen" behilflich sein. Gleichzeitig möchte ich jedoch auch darauf hinweisen, dass es nicht funktionieren wird, die Zusammenhänge in einem Framework zu verstehen und gleichzeitig ohne Erfahrung eines zu schreiben, das deine Anforderungen vollständig erfüllt. Insbesondere beim Thema HMVC habe ich nun schon > 5 Diskussionen zur Implementierung des Pattern geführt und noch nicht eine Implementierung zu Gesicht bekommen, die deine Requirements erfüllt.

Ich möchte auch nochmal betonen, dass es nicht weh tut und auch noch keinen umgebracht hat, etwas zu verwenden, was andere für die Allgemeinheit zur Verfügung stellen. Ferner hindert es dich nicht diese Arbeit auch zu verstehen, die Konzepte kennen zu lernen, das Tool auszubauen und so weiter... Für deinen Lernerfolg ist es als mitnichten notwendig HMVC selbst zu schreiben.

Zitat:

Zu dem hilft es mir bei Entwicklung bei uns im Unternehmen

Lernen, Lernen, Lernen.

In einem Unternehmen ist das Lernen jedoch an Bedingungen geknüpft. Projekte haben Timelines und Qualität ist keine Wunschvorstellung, sondern Anforderung! Sicher ist es wichtig in Projekten zu lernen und sich mit neuen Konzepten vertraut zu machen, der richtige Satz an Basis-Werkzeug ist jedoch von großer Bedeutung. Warum also selbst schreiben, wenn es bereits gute Tools gibt? Im Bereich HMVC ist das APF beispielsweise über Jahre getestet und produktiv eingesetzt und wird stetig weiterentwickelt. Du kannst dir also sicher sein, dass es deine tägliche Arbeit unterstützt.
In der Diskussion mit den Entwicklern und Anwendung kannst du sehr viel über die Konzepte lernen und verstehen wie das Framework intern tickt sowie die Anwendung der Möglichkeiten in deinen Projekten.

Kurzum: wenn du zum Thema HMVC etwas lernen möchtest, nimm dir das APF zur Hand und wir diskutieren. Ich bin mir sicher, das bringt dich weiter.

xm22 · 09.02.2011, 18:22

Zitat:

Gesonderte Requests halte ich für problematisch

Ich bin mir ziemlich sicher, er meint das in der Form, wie das bei Kohana gehandhabt wird. Dort wird die HMVC-Struktur auch über "interne" Requests gesteuert.

mbunge · 17.02.2011, 11:34

Zum Thema HMVC:

ich verwende hierfür interne Requests. Diese Requests sind losgelöst und wissen nichts von den anderen Requests.

Allerdings funktioniert es bei mir nicht genau so wie Kohana.

Seitenaufruf:

Ich habe einen Frontcontroller, dieser führt beim Dispatch einen Adapter aus. Dem Adapter wird das Request-Objekt übergeben. Der Front-Controller soll nicht wissen was er ausführt -> lose Koppelung. Der Adapter ermittelt anhand des Get-Requests "sx_request" welcher Adaptee (Controller, Module, Presentationen oder andere Komponenten) ausgeführt werden soll. Der Request geht durch einen Router. der Router parsed den Request anhand eines Routepattern, das man nach belieben über eine definierte Syntax festlegen kann. Natürlich kann man auch mehrere Pattern definieren.

Dann habe ich einen Layer-Controller, der den Front-Controller um eine Create-Metode erweitert. Die Create-Methode erlaubt das manuelle aufrufen von Commands. Hier ist es dann möglich neue Requests abzusetzen.

Der Layercontroller soll in der Command-controller-schicht sowie in der Presentationschicht zur Verfügung stehen.

Nach obriger Erleuterung ist demnach das Gestalten einer HMVC-Applikation über Presenter (APF) sowie über Controller (Kohana) möglich.

Kurz das Routepattern zur Erläuterung:

[{adapter}:]{path}[[~]{adapter}:{path}]

Adapter: Festlegen von Controller, Modul, Presenation und benutzerdefinierten Adaptern. Als Default-Wert ist Controller vorgegeben.

Path: ein virtueller Pfad. Der Pfad ist abhänig vom Adapter.

Ein kurzes Beispiel:

seite.tld/?sx_request=controller:hello-world/index/param1/param2/param3~modul:ein-tolles-modul/param1/param2

Dieses Beispiel ruft den Controller App_Controller_Hello_World im Ordner {root}/Controller/Hello/World auf und führt die Methode index mit den Parametern auf.

Anmerkung: alle vordefinierten Werte sind konfigurierbar.

MfG
Marco

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
[Suche]Website Umsetzung	tim84	Gewerblich	1	25.01.2011 00:02
[Erledigt] Areya sucht Projekte aller Art zur Umsetzung.	Areya	Beruflich	0	08.01.2011 16:15
[Erledigt] HMVC - 2 verschiedene Interpretationen	bitsnack	Software-Design	7	07.10.2010 10:37
[Erledigt] Framework Kernel Konzept	Geryon	Software-Design	36	06.10.2010 22:23
HMVC: APF vs. Kohana	hts	Software-Design	15	05.10.2010 22:49
Denkanstoß Umsetzung Benutzerverwaltung	Lucifer	PHP Tipps 2010	20	29.04.2010 10:57
Konzept einer Datenbankabstraktion	Dark Guardian	Software-Design	29	30.01.2010 18:13
Integration eines Pluginsystems in einer HMVC Struktur	Anyone	Software-Design	17	21.12.2009 20:10
[Erledigt] Konzept für einen PHP Web Crawler	Dark Guardian	Software-Design	10	23.11.2009 16:31
Professionelle und zeitnahe Umsetzung Ihrer Projekte	STeresiak	Beitragsarchiv	0	26.10.2009 16:12
Konzept für Bowsergame	Wiillli	Beitragsarchiv	1	21.10.2009 15:18
Probleme bei der Umsetzung	Kein Genie	PHP Tipps 2007	3	02.03.2007 15:43
[Browsergame] Hilfe bei Umsetzung		Beitragsarchiv	28	05.03.2005 09:16
[Erledigt] Multigaming Warscript Konzept		PHP-Fortgeschrittene	6	30.08.2004 20:56

21.01.2011, 16:33
mbunge Benutzer Registriert seit: 06.01.2011 Beiträge: 36 PHP-Kenntnisse: Fortgeschritten	[Erledigt] HMVC - mein Konzept zur Umsetzung Werte PHPler, im Zuge einer Lightweight-Framework-Eigenentwicklung, möchte ich das aktuelle MVC Pattern um das HMVC (Layerd MVC) erweitern. Standart mäßig wird beim Start einer Application der Frontcontroller geladen. Die Routerklasse sagt dann welcher ActionController geladen werden soll. Im ActionController soll man die Möglichkeit haben andere Controller reinzuladen. Den ActionControllern werden die Request und Response-Objekte übergeben, um sicher zu gehen ob es sich wirklich um Request / Reponse-Objekte handelt wird Type-Hinting verwendet. Request und Responseobjekte sind als Singleton realisiert. Meine Idee war jetzt einen LayerController (eine Art FrontController zu verwenden). Diesem LayerController kann man 2 Parameter übergeben. Parameter 1 entspricht dem Controllernamen. der ActionControllername kann als der Klassennamen und / oder Pfad übergeben werden. Als 2 Parameter soll ein alternatives Array für die Übergabe von optionalen Werten für das Request / Response Objekt sein. Der LayerController lädt den aktuellen Request / Response automatisch ein. Und erweitert Req. Resp. ggf um werte bzw. überschreibt diese. Zudem habe ich überlegt, dass die Manipulation von Header, also die Setter, innerhalb eines Layer nicht möglich sein soll, da diese bereits im Parent-ActionController gesetzt werden. Zusätzlich gibt es eine Methode die es Ermöglicht den Zugriff des LayerController auf einen ActionController zu verhindern, wenn dieser kein Layer sein soll / darf. Hier ein Beispiel innherhalb eines ActionController: PHP-Code: <?php /** * This file is part of the SXPHP-Framework. * (c) 2011 Marco Bunge * * For the full copyright and license information, please view the LICENSE * file that was distributed with this source code. * @author Marco Bunge * @copyright Marco Bunge 2011 * @category SX * / /* * * Application_Controllers_Default class. * * @package Application_Controller * / class Application_Controller_Action_Index extends SX_Core_Controllers_Action { public function __construct(){ parent::__construct(); //Dieser Actioncontroller soll nicht as Layer verwendet werden $this->disableLayering(__CLASS__); } public function index(){ $customRequest = new stdClass(); //HTTP-Get Vars manipulieren $customRequest->getVars = array('hello' => 'world', 'send' => true); $layerLoginForm = $this->getLayer('forms/auth/loginWidget', array('request' => $customRequest)); unset($customRequest); $customRequest = new stdClass(); //HTTP-Get Vars manipulieren $customRequest->getVars = array('hello' => 'world', 'send' => true); //ActionController als Layer laden $layerLatestBoardEntries = $this->getLayer('forum/latestEntriesWidget', array('request' => $customRequest)); //Variable-Collection des latestEntriesWidget ActionControllers holen $boardVars = $layerLatestBoardEntries->getAssignedVarsObject(); //Die gesamte Ausgabe des LoginFormWirdget-ActionControllers in eine Variable speichern $this->assignVar('loginForm', $layerLoginForm->dispatch()); //eparate Variablen zuweisen $this->assignVar('latestBoardEntriesTitle', $boardVars->title); $this->assignVar('latestBoardEntriesCreationDate', $boardVars->creationDate); //View anzeigen $this->htmlView('startseite', $data); } } Was haltet ihr von dem Konzept? Was würdet ihr andersmachen und warum? Wo seht ihr Schwierigkeiten? Für Kritik bin ich offen MfG Marco Geändert von mbunge (21.01.2011 um 19:39 Uhr). Grund: Fehler in Beispiel PHP behoben.*


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

25.01.2011, 07:44
mbunge Benutzer Registriert seit: 06.01.2011 Beiträge: 36 PHP-Kenntnisse: Fortgeschritten	Hi, erst einmal vielen Dank für eure Antworten. @ G. Schuster: Danke für den Tipp. Darüber werde ich meine Gedanken schweifen lassen, wenn ich meine Konzept zu HMVC (PAC) abschließend fertig gestellt habe. Ich nehme an die init-Methode wird als "Constructor-Ersatz" aufgerufen. @ Dr. e.: Generell danke für die Erleuterung. Die Froum-SuFu hat mir ein hilfreiche Themen ausgespuckt und ich werde mich mal in das PAC-Pattern reinarbeiten. Allgemein bin ich am überlegen, ob ich aktuell wirklich eine hierarchische Struktur in meinem Framework brauche. Es gibt ja auch die Möglichkeit Subcontroller / Widgetcontroller zu nutzen. Weitere Gedanken habe ich mir dazu nicht gemacht. Vorerst werde ich weitere Informationen sammeln und eine Pro / Kontr-Liste aufstellen und dann einen Nutzungsvergleich meines Frameworks aufstellen. Wenn ich eine Lösung gefunden habe werde ich Sie euch im Detail mitteilen. Edit: ein erster Ansatz: 1. Der ActionController (per Routing definiert) wird aufgerufen. Sofern keine Methode (ebefalls im Router definiert) angegeben wurde wird index() aufgerufen. (Wie vorher) 2. Über den LayerController kann man weitere ActionController laden. Im Layercontroller werden die Request und das ResponseObject an den neuen ActionController übergeben (neu: Es kann nichts mehr manipuliert werden, der Router hat keinen Effekt). Es wird das komplette Objekt zurückgegeben. ActionMethoden bzw. View-Variablen aus den ActionMethoden können an Variablen im Haupkontroller übergeben werden. Ich sehe da aber immer noch Probleme. Zum einen ist dieses Vorgehen unflexibel, da für jede ActionMethode das Layer erneut eingebunden werden muss. Dies kann im Konstruktor geschehen, jedoch wirken sich änderungen auf jede ActionMethode im ActionController aus. MfG Marco Geändert von mbunge (25.01.2011 um 09:57 Uhr).

04.02.2011, 15:51
mbunge Benutzer Registriert seit: 06.01.2011 Beiträge: 36 PHP-Kenntnisse: Fortgeschritten	Hallo PHPler, Nach langem überlegen, konzipieren, Papier zerknüllen und neu-denken bin ich zum Schluss gekommen, dass beste Lösung, ein HMVC-Pattern zu etablieren, die einbindung über Views ist. Heute möchte ich keine PHP-Beispielcode präsentieren, eher möchte ich euch erzählen welche Ideen, (die nichts mit HMVC zu tun haben) mir noch gekommen sind. Bei mienen Überlegungen ist immer der Aspekt der Wiederverwenbarkeit ins auge gesprungen, dies war bei meinem Eingangspost nicht gegeben. Darum beruhen meine Nachfolgenden Ideen auf die Wiederverwendbarkeit von Quellcode. 1. HMVC - meine Gedanken. Einleitung: Wie es beim APF überlich ist werde ich die HMVC-Implementierung unteranderem per View einbinden. Die geschieht über einen Event-Handler, der es erlaubt neben einer MVC-Triade auch ausgelagerte Views oder Layer einzuladen. Eventbasiertes einladen von Komponenten (besseres Wort...?) MVC-Triade Eine MVC-Triade besteht aus dem MVC-Pattern. Dafür wird eine gesonderter Request erstellt und ggf. mit einem Response zurückgegeben. Der response kann dann per print, echo etc. ausgegeben werden. ausgelagerte Views Durch das laden einer Ausgalagerten view kann die Weiderverwendbarkeit erhöht werden. sinn macht dies wenn man Views nur für bestimme Einsätze laden möchte und dieser View keine Logik benötigt. Bspw. Header, Footer ohne Logik. Layer Ein Layer besteht aus einem assioativen Array, in dem wiederum Views, Layer und MVC-Triaden per Request angesteuert werden können. Das Array kann n-fach geschatelt werden. Ein Layer hat folgende Form: PHP-Code: <?php //Layerarray array( 'request' => array( /* * action:action_controller/action * view:view_name * layer:layer_name / 'route' => 'key:value', / * Request-Method / 'post' => array( 'user_id' => '1', 'anotherparam' => 'hello' ) ), 'response' => array( 'output_type' => 'xhtml' ), / * Child of current Layer / 'child' => array() ) ?> Das Array wird Rekursiv abgearbeitet und Layer-Elemente werden während der Abarbeitung ausgeführt. 2. ausggelagerte Action-Methode im Action-Controller* Actions sind Methoden in einer Action-Controller-Klasse. Hat man jetzt n Controller mit der selben Action, die ein und die selbe Logik ausführt, ist auf Grund der Wiederverwendbarkeit nur sinnvoll, die Action als Klasse auszulagern. Für die Action-Klasse wird das Command-Pattern genutzt. Nun hat man einen Action-Command Im action-Controller kann man mit den Action-Command per __call aufrufen. __call sollte sinnigerweise in der Elternklasse definiert werden. Soweit mit meinen Gedanken. Kritik, Weitere Ideen Verbesserungen sind erwünscht! MfG Marco

04.02.2011, 19:17
mbunge Benutzer Registriert seit: 06.01.2011 Beiträge: 36 PHP-Kenntnisse: Fortgeschritten	Ich möchte einfach die Zusammenhänge in einem Framework verstehen. Und weil Software im Grunde genommen auf einem minimalen Framework aufbauen, öchte ich soetwas nachbauen. Zu dem hilft es mir bei Entwicklung bei uns im Unternehmen Lernen, Lernen, Lernen. MfG

17.02.2011, 11:34
mbunge Benutzer Registriert seit: 06.01.2011 Beiträge: 36 PHP-Kenntnisse: Fortgeschritten	Zum Thema HMVC: ich verwende hierfür interne Requests. Diese Requests sind losgelöst und wissen nichts von den anderen Requests. Allerdings funktioniert es bei mir nicht genau so wie Kohana. Seitenaufruf: Ich habe einen Frontcontroller, dieser führt beim Dispatch einen Adapter aus. Dem Adapter wird das Request-Objekt übergeben. Der Front-Controller soll nicht wissen was er ausführt -> lose Koppelung. Der Adapter ermittelt anhand des Get-Requests "sx_request" welcher Adaptee (Controller, Module, Presentationen oder andere Komponenten) ausgeführt werden soll. Der Request geht durch einen Router. der Router parsed den Request anhand eines Routepattern, das man nach belieben über eine definierte Syntax festlegen kann. Natürlich kann man auch mehrere Pattern definieren. Dann habe ich einen Layer-Controller, der den Front-Controller um eine Create-Metode erweitert. Die Create-Methode erlaubt das manuelle aufrufen von Commands. Hier ist es dann möglich neue Requests abzusetzen. Der Layercontroller soll in der Command-controller-schicht sowie in der Presentationschicht zur Verfügung stehen. Nach obriger Erleuterung ist demnach das Gestalten einer HMVC-Applikation über Presenter (APF) sowie über Controller (Kohana) möglich. Kurz das Routepattern zur Erläuterung: [{adapter}:]{path}[[~]{adapter}:{path}] Adapter: Festlegen von Controller, Modul, Presenation und benutzerdefinierten Adaptern. Als Default-Wert ist Controller vorgegeben. Path: ein virtueller Pfad. Der Pfad ist abhänig vom Adapter. Ein kurzes Beispiel: seite.tld/?sx_request=controller:hello-world/index/param1/param2/param3~modul:ein-tolles-modul/param1/param2 Dieses Beispiel ruft den Controller App_Controller_Hello_World im Ordner {root}/Controller/Hello/World auf und führt die Methode index mit den Parametern auf. Anmerkung: alle vordefinierten Werte sind konfigurierbar. MfG Marco Geändert von mbunge (17.02.2011 um 12:07 Uhr).