Magento: die offizielle Entwicklerzertifizierung
Kommentare

Working with the Database in Magento (12 %)
Schon lange ist die Magento-Datenbank keine Blackbox mehr. Sofern ein Entwickler weiß, was er tut, spricht nichts dagegen, auch direkt mit der Datenbank zu

Working with the Database in Magento (12 %)

Schon lange ist die Magento-Datenbank keine Blackbox mehr. Sofern ein Entwickler weiß, was er tut, spricht nichts dagegen, auch direkt mit der Datenbank zu arbeiten. Entsprechend den Best Practices sollte das aber nur innerhalb von Resource Models stattfinden. Natürlich sind hartkodierte Tabellennamen verboten, das heißt, Wege, den Namen einer Tabelle zur Laufzeit von einem Objekt zu bekommen, sind gefragt. Ein guter Einstiegspunkt ist Mage_Core_Model_Resource. Die Resource Models von Flat-Table-Entitäten liefern zum Beispiel die passende Tabelle mit getMainTable(). Der Familie der Resource Models gehören auch Collections an. Sie abstrahieren die darunter liegenden Datenbankstrukturen. Die Parametrisierung der addFieldToFilter()– und addFieldToSelect()-Methoden und deren Umwandlung von der Collection in SQL kann natürlich bei jedem Gebrauch nachgeschlagen werden, das wird aber bei der Prüfung auch verlangt. Gerade die Feinheiten von Collections können das Leben eines Entwicklers deutlich angenehmer machen, wenn er sie denn kennt. Typischerweise sind im Zusammenhang mit Collections oft SQL Joins nötig, um alle benötigten Daten laden zu können. In dem Kontext sind Kenntnisse der Zend_Db-Klassen, besonders Zend_Db_Select, sehr praktisch. Auch die Konfiguration von Verbindungen zu anderen MySQL-Datenbanken und moduleigene Lese- und Schreibressourcen sollte der Prüfling kennen. Ein weiteres wichtiges Thema in diesem Bereich sind Setup-Skripte. Das Erstellen neuer Entitäten benötigt (fast) immer auch Tabellen, in denen die Datensätze gespeichert werden.

Zu beachten ist, dass die Zertifizierung noch auf Magento 1.5 (CE) beziehungsweise Magento 1.10 (EE) basiert. Deswegen deckt sie noch nicht das neue Resource-Model-Schema mit Unterstützung für andere Datenbanken neben MySQL ab. Wer sich trotzdem schon einmal damit beschäftigen möchte, dem sei das Dokument unter [3] empfohlen.

Entity Attribute Value (EAV) Model (10 %)

Dieser Themenbereich überschneidet sich zum Teil mit Working with the Database. Allerdings wird hier nicht nur auf die Tabellenstruktur und die Beziehungen der EAV-Tabellen eingegangen, es geht auch um die Unterschiede auf Klassenebene. Aktuell wird das EAV-Schema in Magento nur noch für Entitäten aus dem Catalog- und dem Customer-Modul genutzt. Die Vorteile von EAV liegen in der Attributverwaltung, wobei das einfache Hinzufügen oder Verändern von Attributen noch der kleinste ist. Das ließe sich auch einfach durch das Hinzufügen von Tabellenspalten realisieren. Allerdings eröffnen Attribut-Backend, -Source, -Frontend und Entity Increment Models viele Möglichkeiten, um Features zu bauen und wiederverwendbaren Code zu schreiben. Auch Attributwerte mit einem Gültigkeitsbereich pro Store View sind über das EAV-Datenschema implementiert. Ein zertifizierter Entwickler sollte all diese Werkzeuge einzusetzen wissen. Meistens sind Entitäten, die auf Flat Tables und auf EAV aufbauen, von Entwicklern austauschbar zu behandeln. Nur in wenigen Situationen unterscheiden sie sich. Zum Beispiel wird die DB-Tabelle von Flat-Table-Entitäten mit $model->getResource()->getMainTable() ausgelesen, für EAV-Entitäten ist die Methode jedoch $model->getResource()->getEntityTable(). Sobald Resource Collections ins Spiel kommen, gibt es jedoch noch deutlichere Unterschiede, beispielsweise beim Hinzufügen von Filtern. Diese zu kennen, kann viele Stunden Entwicklungsarbeit sparen, und entsprechend werden sie auch in der Prüfung abgefragt.

Wie lassen sich die Vorteile von Flat-Table-Entitäten mit der mächtigen Attributarchitektur von EAV-Entitäten verbinden? Durch den EAV-Attribut-Datentyp static lassen sich Attributwerte direkt in einer Entitätentabellen speichern. Trotzdem können Backend und Source Models eingesetzt werden, da die Attribute auch in der eav_attribute-Tabelle aufgelistet sind. Gerade bei Vorgängen mit einer großen Menge an Datensätzen wie INSERT, UPDATE und JOIN hat eine einfachere Tabellenstruktur Vorteile.

Adminhtml (8 %)

Die Systemkonfiguration kann über die system.xml-Datei eines Moduls sehr einfach erweitert werden. Unter anderem kann durch die XML Tags , und beeindruckende Funktionalität umgesetzt werden. Dass ein allerdings eine Block-Klasse anstatt eines Models erwartet, ist einer der Fallstricke, die ein erfahrener Magento-Entwickler kennen sollte. Neben der Erweiterung der Systemkonfiguration sind eigene Grids und Formulare zum Bearbeiten von Entitäten wohl die häufigsten Anpassungen der Admin-Oberfläche. Die Grundlagen des Admin-Interface sind die gleichen wie im Frontend: Action Controller, Layout-XML, Blöcke und Templates. Das Arbeiten mit dem auf dieser Basis aufbauenden Adminhtml-Widget-System unterscheidet sich jedoch sehr von den Frontend-Seiten. In der Regel wird im Backend nur ein einziger Block im Layout-XML, also Container, deklariert. Aus dessen Eigenschaften ergeben sich dann die Klassen aller Kindblöcke. Ein weiterer wichtiger Aspekt bei der Arbeit mit der Admin-Oberfläche ist die Zugangskontrolle. In Magento wird sie neben der Authentisierung als Admin-User über eine ACL abgebildet. Das muss sowohl beim Erstellen von eigenen Grids und Formularen als auch bei der Anpassung der Systemkonfiguration beachtet werden.


Themen der folgenden Seiten:

  • Catalog (10 %)
  • Checkout (15 %)
  • Sales and Customers (12 %)
  • Advanced Features (13 %)
  • Additional Objectives for the Plus Form
  • Fazit
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -