Erstellen eines Backend-Moduls: Grundlagen und Konfiguration
Grundlegende Erkenntnisse
Magento ist prinzipiell modular aufgebaut. In Version 1.3 besteht Magento aus zirka 50 Core-Module, deren Funktionalität sich durch weitere Community- oder Local-Extensions erweitern und verändern lässt.
Das Backend ist, was dies angeht eher ein schlechtes Beispiel: Es ist nicht modular aufgebaut, wie man dies vom Frontend her gewohnt ist – die meisten Standard-Interfaces befinden sich im Modul „Adminhtml“. Für den Entwickler hat dies einige Nachteile, wie sich im Laufe der Beitragsserie zeigen wird.
Trotzdem bietet auch das Backend einige Möglichkeiten, bestehende Funktionalitäten anzupassen und zu erweitern. Wie das geht, werden wir in den kommenden Wochen mit einigen kleinen Beiträgen anhand einiger bestehender Module beschreiben. Die Möglichkeiten werden in diesen mit Sicherheit nicht ausgeschöpft – falls wir was Wichtiges vergessen haben sollten, weißt uns bitte drauf hin.
Dieser erste Beitrag beschäftigt sich mit den Teilen der Konfiguration, die für die Erstellung von Backend Interfaces interessant sind.
Die Konfiguration
Wie jedes Modul benötigen auch Backend-Module Konfigurations-Einstellungen, die über die Definitionen der config.xml eingestellt werden. Die allgemeinen Einstellungsmöglichkeiten wie die Definition von Models, Blocks oder Helpern sind nicht Bestandteil dieses Beitrags; viel mehr soll fokussiert auf die speziellen Einstellungen für Backend-Module eingegangen werden.
Der <modules>-Block
Im ersten Block werden allgemeine Informationen zum Modul definiert, wie der Name, die Version und ob das Modul aktiv ist oder nicht:
<modules> <Flagbit_Glossary> <active>true</active> <codePool>local</codePool> <version>0.2.0</version> </Flagbit_Glossary> </modules>
Der <admin>-Block
Nachdem wir im modules-Block zunächst allgemeine Informationen über das Modul gegeben haben, bietet der zweite Block zwei wichtige allgemeine Einstellungen des Magento-Backends: die Registrierung unseres Admin-Controllers sowie die Definition unserer Adressen.
<admin> <routers> <glossary> <use>admin</use> <args> <module>Flagbit_Glossary</module> <frontName>glossary</frontName> </args> </glossary> </routers>
Damit ein Modul überhaupt eigene Informationen verarbeiten kann, muss es einen oder mehrere Controller bei den Routern definieren können. (Action-)Controller sind für die Steuerung der Abläufe und Prozesse innerhalb der MVC-Architektur von Magento zuständig. Router wiederum sind Controller, die einen bestimmten Aufruf anhand der Adresse an einen Action Controller übergeben.
Innerhalb des routers-Block verstecken sich folgende Angaben (vgl. Mage_Core_Controller_Varien_Router_Standard :: collectRoutes()):
- Das XML-Tag <glossary> bestimmt den Namen der aktuellen Route. Auf diese Art und Weise wäre es möglich, bestehende Routen über ein eigenes Modul zu überschreiben.
- Im Backend ist es natürlich wichtig, dass alle Sicherheitsbestimmungen greifen und die Interfaces nicht aus dem Frontend aufgerufen werden können. Dementsprechend wird hier der Wert „admin“ übergeben.
- Das Module beschreibt natürlich das aktuelle Modul.
- Der FrontName wiederum bestimmt, unter welcher URL das eigene Modul aufgerufen werden kann. In unserem Fall wäre dies „http://www.example.com/glossary“.
<rewrite> <Flagbit_Glossary> <from> <![CDATA[#^/{adminhtml}/glossary/#]]> </from> <to>/glossary/admin/</to> </Flagbit_Glossary> </rewrite> </admin>
Um das Backend-Modul nun optimal in das Magento-Backend zu integrieren, sollten sich auch die URLs des Moduls an den Admin-Adressen orientieren – die bisherige URL sieht eher wie die im Frontent aus. Hierfür steht der <rewrite>-Block, der alle Aufrufe von „/{adminhtml}/glossary“ auf den AdminController unseres Frontnames weiterleitet. ”{adminhtml}“ ist hierbei als Platzhalter für das die Adresse des Backend zu verstehen – dieser wird von Magento automatisch ausgetauscht. Als Resultat wird dem Nutzer automatisch unser AdminController angezeigt, wenn er den “GlossarController von Adminhtml” aufrufen möchte.
Der <adminhtml>-Block
<adminhtml> <menu> <cms> <children> <glossary translate="title" module="glossary"> <title>Glossary</title> <action>adminhtml/glossary</action> <sort_order>50</sort_order> </glossary> </children> </cms> </menu>
Der erste Teil des XML-Blocks beschreibt die Einbindung unseres Moduls in das Menü des Backends. Die Hauptmenü-Punkte sind Kindknoten von <menu>; in unserem Fall bauen wir keinen neuen Punkt in der ersten Ebene ein, sondern fügen einen neuen Unterpunkt zu CMS hinzu.
<cms> versteht sich als Referenz auf die Definitionen, die in der config.xml des CMS-Moduls eingefügt wurden – so könnten andere Module wiederum auf die Definitionen von <glossary> zugreifen und diese ändern oder erweitern. Zu beachten ist hierbei auch, dass zwei Module einer Extensions auch eindeutige Keys benötigen!
<title>, <action> und <sort_order> sind an sich selbsterklärend; bei <action> sollte nach Möglichkeit die Adresse angegeben werden, die wir im <rewrite> definiert haben.
<acl> <resources> <admin> <children> <cms> <children> <glossary translate="title" module="glossary"> <title>Glossary</title> <sort_order>50</sort_order> </glossary> </children> </cms> </children> </admin> </resources> </acl> </adminhtml>
Der <acl>-Bereich ist bezüglich des Aufbaus verwandt mit dem beschriebenen Menü. Er ermöglicht die Rechteverwaltung im Backend von Magento. Logischerweise wird der Glossar auch hier wieder als Kindknoten von CMS definiert.
Als Resultat gibt es in der Rechteverwaltung eine neue Checkbox – beim Generieren des Menüs und Aufruf des Moduls wird überprüft, ob das entsprechende Häkchen gesetzt ist oder eben nicht. Als Hinweis sei erlaubt, dass beim Testen der Rechte ein neuer Login Wunder bewirken kann, da die Rechte beim Login überprüft und in die Session des Nutzers gespeichert werden.
Die gesamte config.xml
Wie die gesamte Konfiguration aussehen kann, zeigt das folgende Listing:
<?xml version="1.0"?> <config> <modules> <Flagbit_Glossary> <active>true</active> <codePool>local</codePool> <version>0.2.0</version> </Flagbit_Glossary> </modules> <admin> <routers> <glossary> <use>admin</use> <args> <module>Flagbit_Glossary</module> <frontName>glossary</frontName> </args> </glossary> </routers> <rewrite> <Flagbit_Glossary> <from> <![CDATA[#^/{adminhtml}/glossary/#]]> </from> <to>/glossary/admin/</to> </Flagbit_Glossary> </rewrite> </admin> <adminhtml> <menu> <cms> <children> <glossary translate="title" module="glossary"> <title>Glossary</title> <action>adminhtml/glossary</action> <sort_order>50</sort_order> </glossary> </children> </cms> </menu> <acl> <resources> <admin> <children> <cms> <children> <glossary translate="title" module="glossary"> <title>Glossary</title> <sort_order>50</sort_order> </glossary> </children> </cms> </children> </admin> </resources> </acl> </adminhtml> </config>
Fazit
Im ersten Beitrag zur Entwicklung von Backend-Modulen haben wir die Definitionen der Konfiguration kurz unter die Lupe genommen. Mangels Dokumentation fällt deren Interpretation nicht immer leicht – den Platzhalter für {adminhtml} mussten wir uns auch im Quelltext zusammensuchen.
Mit der Konfiguration konnten wir den Grundstein für die Entwicklung von Backend-Modulen legen, indem wir unsere Controller registriert und in das Menü mit eingebunden haben. Viel Funktionalität haben wir damit natürlich noch nicht – in den kommenden Beiträgen werden wir diese Hülle mit Leben füllen.
