Modularität durch Bausteine
Modularität durch Bausteine
In diesem Beitrag zum Thema [CodeIgniter] HMVC – Entwurfsmuster mit CI, werde ich weiterhin auf die modulare
Entwicklung eingehen. Dazu werden wir uns ein Beispiel-Modul nehmen.
In diesem Artikel werde ich explizit auf die ersten Erfahrungen für die modulare Entwicklung eingehen. Dabei werden wir uns darauf konzentrieren die Grundlagen von HMVC zu erlernen, die Vorteile davon zu erkennen und das erste eigene Modul für CodeIgniter entwickeln.
Zu den Kernschwerpunkten gehören folgende Punkte die wir behandeln werden:
Zu aller erst müssen wir uns überlegen, woraus in CodeIgniter eigentlich ein Modul alles bestehen kann. Wir wissen nun mittlerweile das ein Modul definitiv aus den drei Kernbestandteilen von MVC besteht (Model, View und Controller). Aber CodeIgniter bietet uns für unsere Module weit mehr Möglichkeiten unser Modul unabhängig zur Anwendung zu gestalten. In der nachfolgenden Grafik werden die weiteren Bestandteile von Modulen in CodeIgniter visualisiert:
Anhand dieser Grafik sehen wir die möglichen Komponenten bei der Entwicklung von Modulen in CodeIgniter.
Die drei roten Kästchen symbolisieren dabei die Kernbestandteile eines jeden Moduls. Wobei im Prinzip ein Modul in erster Linie auch nur aus einem Controller bestehen kann.
Der graue Kasten symbolisiert uns, dass auch eigenständige Konfigurationen für ein einzelnes Modul möglich sind. Hierbei ist es möglich das Routing zu beeinflussen, Autoloading explizit nur für dieses Modul zu setzen, eigene Konfigurationsdateien nur für dieses Modul zu setzen oder andere Konfigurationsparameter aus dem Order /application/config zu überschreiben mit der Gültigkeit nur für dieses eine Modul.
Auch Libraries lassen sich innerhalb von Modulen abbilden und nur für ein entsprechendes Modul zur Verfügung stellen. Nehmen wir als Beispiel wir würden ein XML-API-Modul für ein Reseller-Interface bereitstellen wollen. Dann könnten wir in diesem Ordner uns eine API-Klasse hinterlegen, die diese Funktionalität bereitstellt und nirgendwo sonst außer innerhalb dieses Moduls eine Verwendung finden würde. An anderen Stellen würden wir diese Klasse nicht gebrauchen, aber innerhalb unseres Modules greifen wir ständig daraufhin zurück. Der Vorteil davon ist, die Klasse würde nur geladen werden, wenn wir auf dieses eine Modul zugreifen.
Auch für Sprachdateien bietet die HMVC-Erweiterung eine Option. Hier könnten Sprachdateien hinterlegt werden, die nur innerhalb des einen Moduls ihre Verwendung finden. Es macht auch deutlich mehr Sinn diese Sprachdateien bzw. Sprachvariablen innerhalb dieses Ordners abzulegen. Sie werden nur geladen, wenn das jeweilige Modul gerade aktiv ist und sie schaffen eine deutlich größere Übersicht. Denn „man weiß genau“, dass diese Sprachvariablen explizit zu diesem Modul gehören, schließlich wird dies anhand der Ordnerstruktur signalisiert.
Nun genug zur Einführung, kommen wir einmal tatsächlich zur Entwicklung eines Moduls.
Als erstes gilt es eine saubere Struktur unseres Moduls zu gliedern. Als erstes muss ein neues Modul im Ordner /application/modules definiert werden, dazu muss ein neuer Ordner angelegt werden, der den Modulnamen beinhalten muss (Im übrigen, wird dieser Name auch der Name des Frontend-Controllers für dieses Modul sein).
Als Beispielnamen für unser Modul nehme ich hier an dieser Stelle „example“, welchen ich durch diesen Artikel durchgehend verwenden werde.
Diese Struktur gilt für jedes Modul, welches in CodeIgniter angelegt wird.
Kommen wir nun zu unserem ersten Controller. Diesen habe ich bereits im obigen Absatz exemplarisch anhand der Ordnerstruktur angezeigt.
Dementsprechend wird eine neue Klasse im Ordner /application/modules/example/controllers/ angelegt mit dem Namen „example.php“.
Diese Klasse dient uns als Frontend-Controller für dieses Modul. Sie wird immer dann geladen, wenn die URL http://yoururl.com/example/ geladen wird, dazu müssen keine weiteren Routing-Regeln definiert werden.
Sofern kein eigener Core-Controller angelegt wurde, muss diese Klasse vom Controller „MX_Controller“ erben. Dementsprechend sieht das Grundgerüst für unser Modul wie folgt aus:
<?php
class example extends MX_Controller{
public function index(){
$data = array();
$data["text"] = "Hello World";
$this->load->view("index", $data);
}
}
Wie man anhand dieses Beispiels sehen kann, habe ich hier auch gleich einmal ein View definiert, welches geladen werden soll, wenn die index-Methode aufgerufen wird. Auch hier zeigt die Klasse ein Standard-Verhalten. Die Index-Methode wird im Falle unseres Moduls ausgeführt sobald die URL http://yoururl.com/example/ geladen wird.
Das View wird sofern es im Ordner /application/modules/example/views/ unter dem Namen „index.php“ vorhanden ist geladen. Ist in diesem Verzeichnis keine index.php vorhanden, so versucht CodeIgniter diese Datei aus dem Verzeichnis /application/views/ zu laden.
Anschließend können wir uns den Spaß erlauben und eine entsprechende index-View-Datei im Ordner /application/modules/example/views anzulegen unter dem Namen „index.php“ mit folgenden Quelltext:
<?php echo $text; ?>
Damit sollte nun, wenn die URL http://yoururl.com/example/ aufgerufen wird der Text „Hello World“ verfügbar sein.
Bzgl. von Models, Libraries und Configs, haben wir auch hier wiederum das Standardverhalten von CodeIgniter vorzufinden. Wir können jegliche Klassen unseres Moduls anhand der Standard-Load Methode für die jeweilige Klasse verwenden.
Im Falle von $this->load->model() wird CodeIgniter als erstes Versuchen das Model aus dem Verzeichnis /application/modules/example/models zu laden. Ist es dort nicht verfügbar wird das Model versucht aus dem Pfad /application/models zu laden.
Ebenfalls gleiches tritt auf, wenn versucht wird Libraries, Sprachdateien oder Konfigurationen zu laden.
Auch für das Routing gibt es auch hier wiederum nur modulabhängige Routen, welche sich definieren lassen. Dazu muss eine neue Konfigurationsdatei im Ordner /application/modules/example/config/ mit dem Namen „routes.php“ angelegt werden. Diese erweitert die Standard Routing-Datei explizit nur für dieses eine Modul.
Um das Routing an dieser Stelle zu verdeutlichen, legen wir uns einen weiteren Controller im Ordner /application/modules/example/controllers/ an und benennen diesen als „subcontroller“. Auch diese Klasse muss wieder von MX_Controller erben und eine Index-Methode vorweisen können. Ist dies getan, legen wir uns eine routes.php in unserem Modul-Config Verzeichnis unter /application/modules/example/config/routes.php an.
Wir bauen den Inhalt dieser Konfigurationsdatei wie folgt auf:
<?php
$route["example/index"] = "example/index";
$route["example/subcontroller/index"] = "subcontroller/index";
Anhand dieses einfachen Beispiels definieren wir die URL http://yoururl.com/example nach wie vor als Frontend-Controller Klasse „example.php“ und sagen zusätzlich dazu, dass unter der Url http://yoururl.com/example/subcontroller unser Controllber „subcontroller.php“ geladen werden soll. Damit wird sobald das Modul geladen wird, auch diese Routing-Konfiguration geladen und tritt dann auch in Kraft.
Auch für das Autoloading lassen sich Regeln definieren, die nur innerhalb des Moduls gültig sind. Dazu muss eine weitere Konfigurationsdatei im Ordner /application/modules/example/config mit dem Namen „autoload.php“ angelegt werden.
Diese erweitert das Standard-Autoloading Verhalten von CodeIgniter.
<?php $autoload['libraries'] = array(); $autoload['helper'] = array(); $autoload['config'] = array(); $autoload['language'] = array(); $autoload['model'] = array();
Sie bietet uns damit die gleichen Möglichkeiten wie die Standard-Konfigurationsdatei für das Autoloading nur eben mit der Gültigkeit nur für unser eines Modul.
Im nächsten Part, werden wir uns tiefergehend mit HMVC unter CodeIgniter auseinander setzen.