Archiv für die Kategorie ‘Magento | E-Commerce’

Gelegentlich ergibt sich bei Magento das Problem, das gleichlautende Methoden in verschiedenen Kontexten verschiedene Parameter erwarten und letztlich auch Verschiedenes tun. Ein Beispiel ist die _init()-Methode wie sie in den (Entity-)Models, Resource- und Collection-Models zum Einsatz kommt.

_init() im Entity-Model-Kontext:
Im Entity-Model Kontext dient die _init()-Methode dazu, ein Entity-Model mit einem bestimmten Resource-Model zu “verknüpfen”. Der mittels der _init()-Methode übergebe String wir später über die config.xml des Moduls auf die entsprechende Klasse gemappt und per Mage::getResourceSingleton() instantiiert. Die _init()-Methode erwartet dementsprechend den in der config.xml definierten Model-Group-Name gefolgt vom Dateifpad zur zugehörigen Resource-Model-Datei. Beispielsweise also:

protected function _construct()
{
   $this->_init('sales/order');
}

Hier würde Magento in der config.xml nach dem Model-Group-Name “sales” suchen, dann das zugehörige Resource-Model-Classname-Prefix auslesen und schließlich die angegebene Pfadangabe auf das Dateisystem umsetzen.

_init() im Resource-Model-Kontext:
Im Resource-Model-Kontext wird der _init()-Methode hingegen eine Entität gefolgt von der Angabe der Tabellenspalte übergeben, die die Entitäts-ID beinhaltet. Die zu einem Modul zugehörigen Entitäten sind wiederum in der config.xml im Pfad global/models/resource_model_group_name/entities/name_der_entität festgelegt. Ein entsprechender Aufruf lautet also:

protected function _construct()
{
   $this->_init('sales/order', 'entity_id');
}

_init() im Collection-Model-Kontext:
Im Collection-Model-Kontext wird der _init()-Methode das zugehörige Entity-Model bekannt gemacht. Später wird dann für jedes ausgelesene Tupel ein Model-Objekt der entsprechenden Klasse instantiiert und die Werte per setData() auf das Objekt übertragen. Ein Aufruf entpsrechend unseres Beispiels sieht wie folgt aus:

protected function _construct()
{
   $this->_init('sales/order');
}

Magento-Entwickler, die ihre Extensions per TDD (Test-Driven-Development) entwickeln und dazu die Magento-PHPUnit-Extension von EcomDev nutzen, haben vielleicht schon Probleme mit dem Laden von Fixtures über die entsprechende “@loadFixture”-Annotation gehabt.

Sofern in der Testklasse eine eigene Setup-Methode definiert ist, gelingt das Laden der Fixtures nur, wenn am Ende die Eltern-Methode aufgerufen wird. In ihr werden die nötigen Fixtures überhaupt erst geladen. Eine mögliche Setup-Methode sieht daher wie folgt aus:

public function setUp()
{
 // eigener Setup-Code ...
 parent::setUp();
}

Die CSS-Klasse im Body-Tag verrät die aktuelle Modul-Controller-Action-Kombination. Hier: cms/index/index

Bedingt durch Magentos URL-Rewriting im Frontend ist es meist nicht auf den ersten Blick ersichtlich, welche Modul-Controller-Action-Kombination für die aktuelle Ausgabe verantwortlich ist.

Tipp: Ein Blick in die CSS-Klasse des Body-Tags im HTML-Quellcode verrät meist die aktuelle Modul-Controller-Action-Kombination.

Hier nochmal eine kleine Erinnerung an den kommenden Magento-Stammtisch in Münster:

www.magento-stammtisch-muenster.de