Hallo,
ich bin gerade dabei Frameworks auszuprobieren, weil das ZF2 bei einem Prototyp hier sehr langsam ist. 250ms für eine leere Controller-Action + leeren View sind einfach zuviel.
Jetzt habe ich mir mal das Slim-Framework angeschaut und das ist recht simpel. Ich mappe eine Route auf ein Closure.
Ist nur ein Beispiel, aber so ungefähr. Mit View und ServiceManager eigentlich ganz nette Idee.
Also eigentlich genau das, was ich immer haben wollte. Nur dass ich kein Closure will, sondern eine fixe Klasse. Eine Route = eine Action = eine Klasse.
Das jetzt noch in eine Konfiguration ausgelagert:
Warum wird das allgemein immer noch mit Controllern und Action-Methoden gehandlet? Wenn man dem Prinzip folgt, eine Klasse = eine Aufgabe, also die Änderung einer Klasse sollte nur aus einem einzigen Grund erlaubt sein, dann ist das Konzept Controller-Actions doch schon kaputt, oder? Ganz abgesehen davon, dass ich Code soweit dupliziere, weil er für die meisten Entitäten ja gleich ist: Laden, Speichern, Löschen. Formularverarbeitung, Rechte verwalten, bla.
Ich hab jetzt mal kurz ein Micro-Framework geschrieben, das anhand einer Config Routen auf Action-Klassen mappt (siehe oben Ausschnitt-Beispiel). Wenn man jetzt noch konfiguriert, welche Art von Action es ist (view => mappt Model-Daten in den View; edit = mappt Model-Daten in ein Formular und das Formular in den View; ..) kann man sich doch fast die gesamte Programmierarbeit sparen und schnell ist es ohne den ganzen ZF2-Overhead Firlefanz auch. Diese ganze Adapter-Scheisse nervt mich eh, ich benutz eine einzige Datenbank, hab außer 1x nie den Datenbanktyp geändert. Diese abstrahierten Frameworks produzieren Unmengen an Overhead um Features zu bieten, die am Ende keiner braucht.
Meine Frage ist jetzt tatsächlich:
* Wozu gibt es Controller-Klassen und Action-Methoden, warum mappt man einen Request nicht auf eine Action-Klasse?
* Ist die Idee von mir so neu oder so schlecht, dass ich im Internet dafür nichts finden kann?
Außerdem benötige ich für meine Anwendung mehrere Actions pro Aufruf, da die "Sidebar" auch recht komplex sein wird. Auch das scheint immer nur halbherzig umgesetzt zu sein. Zugegeben altes Problem.
Bei meinem Mini-Micro-Framework (Application + Router + ServiceManager) mappt der Router eine Route auf eine Action-Klasse. Die kann sich per ServiceManager holen was sie braucht. An der Action hängt ein View und vielleicht auch ein Layout. Das Layout selbst kann nun noch mehr Actions beinhalten (Footer, Sidebar, Navigation). Sprich am Ende habe ich einen ActionTree (und damit auch einen ViewTree). Aber ich finde das eigentlich logisch, denn wenn ich die Action ohne Layout lade (z.B. per XHR) brauche ich ja auch die Sidebar-Action nicht. Daher der Weg über das Layout weitere Actions zu identifizieren. Trotzdem kommt es mir unkonventionell vor, wenn ein Layout eine Action laden kann. Naja.
Beim ZF2 scheint es mir nicht ohne Brumbrum möglich, mehrere Actions "auf natürliche Weise" abzuarbeiten. Ich muss dann entweder in jeder Action, die eine Sidebar hat, nochmal "irgendwas" (Controller-Plugin o.ä.) aufrufen, das die Sidebar konfiguriert oder die Konfiguration im View-Helper machen. Damit ist dann gefühlt meine Controller-Action für den Arsch, weil ich noch x Bedingungen einbauen muss, dass z.B. bei einem AJAX-Request die Sidebar doch nicht konfiguriert wird.
Bei meinem Mini-Micro-Framework würde bei AJAX eben das Layout deaktiviert und damit auch die Sidebar wegfallen. Die Idee gefällt mir, ich bin nur nicht sicher ob die Idee wirklich gut ist und ich frag mich, warum das bei bisherigen Frameworks nur so kompliziert möglich ist.
Danke & Gruß,
Chriz
ich bin gerade dabei Frameworks auszuprobieren, weil das ZF2 bei einem Prototyp hier sehr langsam ist. 250ms für eine leere Controller-Action + leeren View sind einfach zuviel.
Jetzt habe ich mir mal das Slim-Framework angeschaut und das ist recht simpel. Ich mappe eine Route auf ein Closure.
PHP-Code:
<?php
$application->get('/project', function() {
echo "project list";
});
Also eigentlich genau das, was ich immer haben wollte. Nur dass ich kein Closure will, sondern eine fixe Klasse. Eine Route = eine Action = eine Klasse.
PHP-Code:
<?php
$application->get('/project', array(
'invokable' => 'JarJar\Project\ListAction'
));
PHP-Code:
<?php
array(
'router' => array(
'routes' => array(
'project/list' => array(
'route' => '/project',
'type' => 'literal',
'action' => 'projectListAction'
)
)
),
'service' => array(
'invokables' => array(
'projectListAction' => 'JarJar\Project\ListAction'
)
)
);
?>
Ich hab jetzt mal kurz ein Micro-Framework geschrieben, das anhand einer Config Routen auf Action-Klassen mappt (siehe oben Ausschnitt-Beispiel). Wenn man jetzt noch konfiguriert, welche Art von Action es ist (view => mappt Model-Daten in den View; edit = mappt Model-Daten in ein Formular und das Formular in den View; ..) kann man sich doch fast die gesamte Programmierarbeit sparen und schnell ist es ohne den ganzen ZF2-Overhead Firlefanz auch. Diese ganze Adapter-Scheisse nervt mich eh, ich benutz eine einzige Datenbank, hab außer 1x nie den Datenbanktyp geändert. Diese abstrahierten Frameworks produzieren Unmengen an Overhead um Features zu bieten, die am Ende keiner braucht.
Meine Frage ist jetzt tatsächlich:
* Wozu gibt es Controller-Klassen und Action-Methoden, warum mappt man einen Request nicht auf eine Action-Klasse?
* Ist die Idee von mir so neu oder so schlecht, dass ich im Internet dafür nichts finden kann?
Außerdem benötige ich für meine Anwendung mehrere Actions pro Aufruf, da die "Sidebar" auch recht komplex sein wird. Auch das scheint immer nur halbherzig umgesetzt zu sein. Zugegeben altes Problem.
Bei meinem Mini-Micro-Framework (Application + Router + ServiceManager) mappt der Router eine Route auf eine Action-Klasse. Die kann sich per ServiceManager holen was sie braucht. An der Action hängt ein View und vielleicht auch ein Layout. Das Layout selbst kann nun noch mehr Actions beinhalten (Footer, Sidebar, Navigation). Sprich am Ende habe ich einen ActionTree (und damit auch einen ViewTree). Aber ich finde das eigentlich logisch, denn wenn ich die Action ohne Layout lade (z.B. per XHR) brauche ich ja auch die Sidebar-Action nicht. Daher der Weg über das Layout weitere Actions zu identifizieren. Trotzdem kommt es mir unkonventionell vor, wenn ein Layout eine Action laden kann. Naja.
Beim ZF2 scheint es mir nicht ohne Brumbrum möglich, mehrere Actions "auf natürliche Weise" abzuarbeiten. Ich muss dann entweder in jeder Action, die eine Sidebar hat, nochmal "irgendwas" (Controller-Plugin o.ä.) aufrufen, das die Sidebar konfiguriert oder die Konfiguration im View-Helper machen. Damit ist dann gefühlt meine Controller-Action für den Arsch, weil ich noch x Bedingungen einbauen muss, dass z.B. bei einem AJAX-Request die Sidebar doch nicht konfiguriert wird.
Bei meinem Mini-Micro-Framework würde bei AJAX eben das Layout deaktiviert und damit auch die Sidebar wegfallen. Die Idee gefällt mir, ich bin nur nicht sicher ob die Idee wirklich gut ist und ich frag mich, warum das bei bisherigen Frameworks nur so kompliziert möglich ist.
Danke & Gruß,
Chriz
Kommentar