Die Methoden der Mage-Klasse und ihre Gegenstücke in Magento 2
Hier sind einige der Methoden der Mage-Klasse in Magento 1 und was daraus in Magento 2 geworden ist:
Mage::getModel($modelClass,$arguments) / Mage::getResourceModel($modelClass,$arguments)
Die getModel und getResourceModel Methoden in Magento 2 wurden, wie schon in den letzten Teilen der Blogserie gezeigt, durch das Laden der Factory des Models ersetzt. Beispiel:
// Magento 1:
class Magento1Beispiel {
function meineTolleMethode() {
$product = Mage::getModel('catalog/preoduct')->load(10);
}
}
//Magento 2:
class Magento2Beispiel {
protected $_productFactory;
function __construct(
\Magento\Catalog\Model\ProductFactory $productFactory
) {
$this->productFactory = $productFactory;
}
function meineTolleMethode() {
$product = $this->productFactory->create()->load(10);
}
}
Mage::getSingleton($modelClass,$arguments) / Mage::getResourceSingleton($modelClass,$arguments)
Hier gilt dasselbe wie bei getModel. Allerdings wird keine Factory verwendet. Wenn wir im Beispiel oben \Magento\Catalog\Model\Product anstatt der Factory laden würden, hätten wir ein Singleton-Objekt des Product Models geladen. Das heißt: Alle Klassen, die diese Klasse via Dependency Injection laden, laden dasselbe Objekt.
Aber Achtung! Dieses Verhalten ist konfigurierbar und möglicherweise reagieren hier nicht alle Klassen gleich. Daher möchte ich an dieser Stelle kurz auf eine Erklärung des Ganzen von Alan Storm (englisch) verweisen. In seinem Artikel zu Instant Objects in Magento 2 führt Alan Storm auch kurz den Object Manager auf. Hierbei handelt es sich um eine alternative Möglichkeit, Objekte zu laden. Sie kommt dem getModel und getSingleton von Magento 1 näher, sollte aber grundsätzlich eher gemieden werden.
Mage::helper($name)
Siehe getSingleton.
Mage::log($message, $level, $file, $forceLog)
Für das Logging verwendet Magento 2 Monolog, allerdings lässt sich – dank einheitlichem Interface – grundsätzlich jeder Logger verwenden. Um zu loggen, einfach das Objekt \Psr\Log\LoggerInterface via Dependency Injection in der eigenen Klasse verlangen. Man bekommt dann die Instanz des aktuell konfigurierten Loggers.
Um nun zu loggen, verwendet man auf dem Objekt Methoden wie log, warning oder critical. Eine Übersicht aller Logger-Methoden lässt sich auf Github finden.
Mage::logException($e)
Lässt sich entweder durch das einfache Werfen von Exceptions in Magento 2 umsetzen oder auch gezielter in Kombination mit dem Logger (siehe oben).
Mage::dispatchEvent($name, $data)
Um ein Event auszulösen, muss \Magento\Event\Manager in die Klasse geladen werden und dann die Methode dispatch mit dem Namen des Events aufgerufen werden.
$this->eventManager->dispatch('event_name');
Mage::getConfig()
Einträge aus der Konfguration können mittels \Magento\Framework\App\Config\ScopeConfigInterface gelesen und geschrieben werden. Beispiel:
$scopeConfig->getValue('dev/debug/template_hints', \Magento\Store\Model\ScopeInterface::SCOPE_STORE);
Mage::getUrl($route,$params)
Es gibt verschiedene Möglichkeiten, in Magento 2 URLs zu ermitteln. Die einfachste ist es, in einem Block oder Template die Methode getUrl zu nutzen. Falls man sich gerade nicht in einem Block oder Template befindet, kann \Magento\Store\Model\StoreManagerInterface geladen werden. Das Interface bietet ebenfalls die Methode getUrl und kann theoretisch auch URLs aus anderen Stores auflösen (siehe unten).
Mage::register($key, $value) / Mage::registry($key)
Die Registry-Befehle register, registry und unregister können via \Magento\Framework\Registry aufgerufen werden und funktionieren vom Prinzip genau wie in Magento 1.
Aktuellen Store abfragen
Als Bonus noch ein hilfreiches Objekt, falls man einen Multi-Store-Shop betreibt. \Magento\Store\Model\StoreManagerInterface bietet viele Methoden, um store-spezifische Daten abzurufen, sowie eine Liste der Stores und Websites und die Information, in welchem Kontext man sich gerade befindet (getStore). Eine vollständige Dokumentation des Interfaces befindet sich auf Github.
Wir hoffen, diese Liste einiger der wichtigsten Methoden und Objekte in Magento 2 wird euch das tägliche Arbeiten mit dem Shopsystem ein wenig erleichtern. Im nächsten Teil unserer Blogserie schließen wir unser Modul quasi ab: Wir werden das Modul mit Resource Models und Collections ergänzen und uns außerdem Install- und Upgrade-Scripte ansehen. Als letztes folgen dann nur noch die Observer und Helper in Magento 2.
Die weiteren Beiträge der Serie
- Magento 2 Modulentwicklung – Teil 1: Vorbereitung
- Magento 2 Modulentwicklung – Teil 2: Frontend Entwicklung
- Magento 2 Modulentwicklung – Teil 3: Controller und Actions
- Magento 2 Modulentwicklung – Teil 4: Models und Dependency Injection
- Magento 2 Modulentwicklung – Teil 6: Resource Models und Install-Scripts
- Magento 2 Modulentwicklung – Teil 7: Observer, Helper und Fazit