Zastanawiałem się, jaki jest właściwy sposób wdrożenia rozszerzalnego modelu EAV.
Widzę Magento\Catalog\Model\Product
, że metoda getExtensionAttributes()
jest implementowana w następujący sposób:
public function getExtensionAttributes()
{
$extensionAttributes = $this->_getExtensionAttributes();
if (!$extensionAttributes) {
return $this->extensionAttributesFactory->create('Magento\Catalog\Api\Data\ProductInterface');
}
return $extensionAttributes;
}
Ale w innych, takich jak modele klientów lub kategorii, jest to po prostu
public function getExtensionAttributes()
{
return $this->_getExtensionAttributes();
}
co może prowadzić do wyniku NULL , jeśli klucz extension_attributes nie był wcześniej ustawiony.
Pragmatycznie wolałbym ten pierwszy. W ten sposób zawsze mogę uzyskać instancję Magento\Framework\Api\ExtensionAttributesInterface
, nawet jeśli model został właśnie utworzony.
Ale dlaczego nie jest używany w innych modułach? Czy jest to sprzeczne z nową separacją modeli danych, którą widzimy w module klienta? Jeśli tak, to jak mamy zainicjować atrybuty rozszerzenia?
źródło
$order->getExtensionAttributes()
i został rozwiązany po kolejność uzyskanie jak poniżej:$order = $this->orderRepositoryInterface->get($order->getId());
. Interfejs repozytorium zamówień toMagento\Sales\Api\OrderRepositoryInterface
. Nie jestem pewien, czy twój problem był taki samKod jest używany w różny sposób w różnych rozszerzeniach. Ta funkcja służy do wiązania dowolnego atrybutu w tym interfejsie. Aby lepiej to zrozumieć, skorzystaj z tego łącza: http://oyenetwork.com/articles/magento2-devliery-date-module-creation-from-scratch/
źródło
getExtensionAttributes()
w encji niestandardowych