studiplogo

Why not Trails?

Das MVC-Framework Trails ist ein einfaches aber in meinen Augen tolles MVC-Framework. Man kann es für die Entwicklung von Plugins für das System Stud.IP benutzen oder man sollte es benutzen wenn man bei Stud.IP etwas im Kern ändert.

Was ist Trails?

Trails ist ein MVC-Framework das von Lunki https://github.com/luniki  entwickelt bzw. auf GitHub gestellt hat. Das Stud.IP Projekt benutzt es und deshalb wollte ich mir das Framework genauer anschauen. Mein Ziel ist es nicht an Stud.IP Kern etwas zu verändern aber meine Plugins (die ich veröffentlichen möchte) sollten sich doch etwas dem Standard entsprechen.

Der Aufbau

Von der Idee her braucht man 3 Ordner
– model
– controller
– view

Ein Model braucht man nicht unbedingt aber sonst hält man sich nicht an die Idee die hinter MVC steht.

Wie bei jedem Stud.IP Plugin braucht man ein plugin.manifest sowie eine Php Datei mit der Plugin-Klasse im Root Verzeichnis des Plugins.

die PHP-Klasse sieht gegenüber „Klassischen“ Plugins etwas anders aus:

Die Funktion __construct (was ja der Konstruktor der Klasse ist)  als ein Menüpunkt auf der Startseite zu erstellen.
Was sich aber zu den Klassischen Plugins unterscheidet ist die Einbindung der trails.php und die Funktion  perform.
Die Aufgabe von Perform ist das einfache Dispatchen aller eingehenden Anfragen an den jeweiligen Controller.

Ein Controller

Ein Controller ist das einzige was eine „Vorgeschriebene“  Form hat. Zum Beispiel der Startcontroller.

Die Funktion before_filter wird immer ausgeführt beim Aufruf des Controllers. Man kann ihn als Konstruktor sehen, aber im Innern von StudIP wird dieser  etwas anders benutzt.

Zusätzlich zu dieser Funktion habe ich in diesem Beispiel zwei Actions hinzugefügt die Ausgeführt werden können. Die Index_Action wird ausgeführt wenn keine spezielle Action angegeben wurde (wenn die url so aussieht /testplugin/start). Die Funktion cooler wird dann ausgeführt wenn der Aufruf folgender Maßen aussieht : /testplugin/start/cooler.

Soweit so einfach, aber das Plugin wird so nicht gehen. Zum einen wird eine Model Funktion aufgerufen und zum anderen fehlen noch die Views.

Zu erst einmal will ich die Views anlegen:

Die Views:

Im View Ordner muss man für jeden Controller einen Unterordner erstellen (Beispiel startController -> Ordner-Name: start). In diesem Ordner muss man für jede Action eine .php Datei anlegen (wie man die gleiche Datei benutzt habe ich noch nicht getestet bzw. herrausgefunden). Also benötigen wir eine index.php sowie eine cooler.php. Der Inhalt ist bei diesem Beispiel gleich:

Jetzt müssen wir nur noch $cool mit etwas füllen. Da beide Actions im Controller eine Model Funktion aufrufen, füllen wir die Variable dort.

Das Model:

Ein Model anzulegen ist einfach und geht schnell.  Es muss nur eine PHP-Datei unter dem Ordner View liegen mit dem Namen der View-Klasse.

 

Durch das setzen von $this->cool setzt Trails die Variable in dem View.

Versenden von Nachrichten

Will man Nachrichten bzw. Informationen (Objekte oder Arrays) übergreifend benutzen, kann man diese als Argumente immer wieder übergeben oder was einfacher ist, bei jeder Klasse im Konstruktor sich die Instanz der Klasse Trails_Flash::instance(); ziehen.

Setzt man diese z.B. auf $this->flash erhält man in jedem Controller oder Model drauf zugriff. Beispiel:

Controller:

Model:

Eine Tolle Sache mit dem Flash.

Fazit

Mich hat das Trails Fieber gepackt, weil es sehr viel Zeit und Denkarbeit spart. Man muss sich nicht mehr um die Ausgabe kümmern oder die Handhabung von Templates im Allgemeinen. Mein Test-Plugin hat ca. 20% weniger Code und ist übersichtlicher.

Danke für das Framework.

Johannes

Hauptberuflich bin ich im Bereich Filesecurity unterwegs und schütze die Daten meines Arbeitgebers vor internen und externen Gefahren.
Nebenberuflich helfe ich KMUs als IT-Consultent bei der IT-Strategie sowie bei der Entwicklung von Webanwendungen.

2 thoughts to “Why not Trails?”

  1. Eigentlich ein schöner Artikel, aber eine Sache ist leider falsch.

    Es geht in PHP zwar, dass man über den Aufruf einer statischen Methode einer zweiten Klasse Objektvariablen an einer Instanz einer Klasse ändern kann, aber das ist weder schön noch sollte man dies einsetzen. Letztendlich verlässt man sich da auf eine Eigenart von PHP, die theoretisch jederzeit mal aus PHP entfernt werden könnte (und sollte!).

    Das Modell sollte autark sein und braucht gar nichts von dem Controller zu wissen. Sonst wird das Debugging furchtbar schwer, da man bei einem $this eigentlich immer davon ausgeht, dass es sich auf die Klasse bezieht, in der man sich gerade befindet.

  2. Danke für dir Rückmeldung.
    Natürlich haben Sie recht. Bei größeren Projekten wird das ganze mit $this auch sehr schlecht lesbar. Das $this->flash habe ich mehr oder weniger mir aus der Dokumentation so (falsch) angewöhnt.

    Ich werde den Artikel ein einigen Stellen überarbeiten, es fehlen ja noch einige Punkte wie der URL Aufbau und das Routing selber auch.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.