Magento: die offizielle Entwicklerzertifizierung
Kommentare

Catalog (10 %)
Da Magento als E-Commerce-Anwendung aufgestellt ist (manchmal scheint es eher ein generisches Framework zu sein), ist das Katalogmodul sehr tief in Magento integriert. Es bestehen viele

Catalog (10 %)

Da Magento als E-Commerce-Anwendung aufgestellt ist (manchmal scheint es eher ein generisches Framework zu sein), ist das Katalogmodul sehr tief in Magento integriert. Es bestehen viele Abhängigkeiten zu anderen Modulen, und einige der komplexeren Aspekte Magentos liegen in diesem Bereich. So zum Beispiel die Generierung der Flat-Catalog-Tabellen, die häufiger die Arbeit eines Entwicklers tangiert, etwa bei der Erstellung eigener Source Models für Attribute. Weitere Indexe aus dem Catalog-Modul sind die URL Rewrites für suchmaschinenfreundliche Produkt- und Kategorie-URLs, die Preisberechnung und der Attributwerteindex für die Filternavigation.

Meiner persönlichen Erfahrung nach eher selten genutzt, aber für die Prüfung als wichtig erachtet, sind eigene Product Type Models. Sie sind ein mächtiges Instrument in der Werkzeugkiste eines Magento-Entwicklers. Häufig reicht in der Praxis jedoch auch eine Anpassung der von Haus aus verfügbaren Produkttypen, um ein gewünschtes Feature umzusetzen. In diesem Themenbereich liegen auch die vielfältigen Produktverknüpfungen: Zunächst einmal diejenigen zwischen Configurable und Bundled Products zu den jeweiligen verknüpften Simple Products. Außerdem gibt es noch die Cross-sell-, Up-sell- und Related-Product-Verknüpfungen. Ein Blick in die Datenbank auf die Verknüpfungstabellen und in die Klassen zum Auslesen der Verbindungen kann sicher nicht schaden. Gut zu wissen für die Plusprüfung: Das Enterprise_TargetRule-Modul baut auf der Cross-sell-, Up-sell- und Related-Product-Funktionalität auf und erweitert diese.

Checkout (15 %)

Die Models checkout/cart, customer/session und checkout/session sind über das sales/quote-Modell eng verbunden. Sich hier auszukennen hilft, einige technische Fehlentscheidungen zu vermeiden (ich spreche da aus eigener Erfahrung). Auch das automatisierte Hinzufügen von Produkten zum Warenkorb ist immer wieder ein Thema. Bei fast jedem größeren Shop werden Anpassungen am Checkout-Prozess vorgenommen, sei es, um externe Systeme einzubinden oder um die Benutzerführung zu verbessern. Dazu sind genaue Kenntnisse des Onepage Checkouts und des Multi-Address Checkouts erforderlich. Nicht zu vernachlässigen sind auch der Callcenter Checkout im Admin-Bereich und die Order-Erstellung über das Checkout SOAP API. Diese vier Möglichkeiten können in Magento ohne weitere Anpassungen benutzt werden, um Bestellungen zu erzeugen.

Sales and Customers (12 %)

Hier gibt es viele Überschneidungen mit dem Checkout-Bereich. Aus Entwicklersicht ist der größere Teil der Low-level-Logik jedoch dem Mage_Sales-Modul zugeordnet. Ein häufig missverstandenes Feature von Magento ist die Art und Weise, wie Bestellungen mit mehreren Adressen umgesetzt sind. Die Klasse, in der die Funktionalität nachgeschlagen werden kann, ist Mage_Checkout_Model_Type_Multishipping. Werden Produkte dem Warenkorb hinzugefügt, so werden sie als Quote Items dem Quote Model und den Adress Models zugeordnet. Die unterschiedlichen Produkttypen werden zwar alle durch Quote Items repräsentiert, allerdings gibt es durchaus Variationen, wie das im Einzelfall gehandhabt wird. So benötigen virtuelle und herunterladbare Products schließlich keine Versandadresse. Auch die Implementierung neuer Payment- und Shipping-Methoden sollte ein Magento-Entwickler, der sich zertifizieren lassen will, nicht scheuen. Zum einen betrifft das die Signatur der jeweiligen abstrakten Klassen, zum anderen die damit zusammenhängenden XML-Strukturen der Konfiguration.

Im Sales-Modul sind auch Rechnungen, Gutschriften und Lieferscheine enthalten. Die benötigten Werte werden dabei von einem Entity Model zum anderen häufig über Fieldsets in der Konfiguration kopiert. Wenn diese Entitäten erstellt werden, beeinflusst das wiederum die verknüpfte Bestellung. Leider lassen sich „Order State“ und „Order Status“ nicht wirklich eindeutig ins Deutsche übersetzen – „Bestellzustand“ und „Bestellstatus“ sind meine Favoriten. Es ist wohl besser, die englischen Begriffe zu verwenden. Wichtig für die Prüfung ist jedoch zu verstehen, wie diese beiden Eigenschaften zusammenhängen und wie sie gesetzt werden.

Advanced Features (13 %)

Wichtige Aspekte des fortgeschrittenen Bereichs sind der Einsatz und die Erweiterung des Magento SOAP APIs. Meistens wird nach wie vor die erste Version des SOAP API benutzt, zumindest wenn Anpassungen erforderlich sind. Für die Zertifizierungsprüfung sollten jedoch auch die Unterschiede und Gemeinsamkeiten zu der Version 2 des API bekannt sein. Der WS-I-kompatible Modus [4] wurde erst mit Magento 1.6 eingeführt und ist deswegen noch kein Bestandteil der Prüfung.

Von Shopbetreibern häufig gefragt sind Anpassungen an Shopping Cart Price Rules. Schon von Haus aus recht vielfältig einsetzbar, sind der Phantasie eines Händlers für Rabattregeln keine Grenzen gesetzt, wenn es gilt, neue Kunden anzulocken. Entsprechend sollte ein zertifizierter Entwickler in der Lage sein, die bereits vorhandenen zu erweitern und neue Regeltypen zu dem Admin-Interface für Shopping Cart Price Rules hinzuzufügen. Auch die Funktionsweise von Coupons auf Codeebene gehört zu diesem Bereich.

Frontend Widgets stehen seit der Version 1.4 zur Verfügung. Diese spielen bei der Zertifizierung keine besonders große Rolle, können aber doch vorkommen. Sie sind im Modul Mage_Widget implementiert, im Gegensatz zu den Backend Widgets, die auf Mage_Adminhtml_Block_Widget und den Derivaten basieren.


Themen der letzte Seite:

    li>Additional Objectives for the Plus Form

  • Fazit
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -