В Magento, как Блоки захватывают данные из моделей?

Ответ 1

Ничто не передает данные в блоки. После того, как действие контроллера выполнило свою модель взаимодействия, оно отвечает за

• Загрузка объекта макета (который косвенно загружает и создает объекты блока)

• Сообщите этому объекту макета для отображения страницы.

Большинство действий контроллера Magento делают это с двумя вызовами в конце действия контроллера.

$this->loadLayout();
$this->renderLayout();

В Magento ничто не устанавливает данные в представлении. Вместо этого представление (т.е. Объекты блока) запрашивает систему для данных. Вы можете увидеть пример этого в классе блоков Mage_Tag_Block_Customer_View.

#File: app/code/core/Mage/Tag/Block/Customer/View.php    
...
public function getTagInfo()
{
    if (is_null($this->_tagInfo)) {
        $this->_tagInfo = Mage::getModel('tag/tag')
            ->load($this->getTagId());
    }
    return $this->_tagInfo;
}    
...

Здесь этот метод getTagInfo запрашивает модель непосредственно для ее информации. Таким образом, разработчик шаблона интерфейса имеет доступ к

$this->getTagInfo();

метод. У меня также есть хороший авторитет, что метод block _prepareLayout - идеальное место для размещения большинства, если не всех, ваших данных, получающих код в блоке.

Второй шаблон, который вы увидите, используется в шаблоне реестра Magento. Это система Magento, которая позволяет вам установить глобальную переменную общесистемной (но не PHP).

Mage::register('foo', 'some value');
echo Mage::registry('foo');

Иногда разработчик Magento будет использовать реестр для установки переменной в действие контроллера, а затем захват возвращается в блоки. Например, в контроллере счета-фактуры администратора.

#File: app/code/core/Mage/Adminhtml/controllers/Sales/Order/InvoiceController.php
protected function _initInvoice()
{
    ...
    $invoice = Mage::register('current_invoice', $invoice);
    return $invoice;
}    

а затем блок будет ссылаться на него позже.

#File: app/code/core/Mage/Sales/Block/Order/Print/Invoice.php
public function getInvoice()
{
    return Mage::registry('current_invoice');
}

Я не одинок по поводу шаблона реестра, но он используется основной командой, поэтому он, вероятно, кошерный.

Наконец, если вы хотите эмулировать шаблон "немой точки зрения", используемый в большинстве инфраструктур PHP MVC, попробуйте что-то вроде этого

$this->loadLayout();
$block = $this->getLayout()->getBlock('block_name');
$block->setSomeData('My Data');
$block->setData('alternate_syntax', 'Some other data');
$this->renderLayout();

а затем в файле блока и/или шаблона.

echo $this->getSomeData();
echo $this->getData('some_data');

echo $this->getAlternateSyntax();
echo $this->getData('alternate_syntax');

После вызова loadLayout Magento создаст все объекты блока. То, что вы делаете выше, получает ссылку на конкретный объект блока и затем устанавливает его данные.

В комментариях к Перу Винай ниже также рассматривается метод блока assign.

Подобно setData, после вызова метода loadLayout (или из блока _prepareLayout) вы можете сделать что-то вроде

$this->loadLayout();
$block = $this->getLayout()->getBlock('block_name');
$block->assign('my_view_var','Something for the view');
$this->renderLayout();

а затем в вашем блочном phtml файле вы сможете вывести эту переменную вида

echo $my_view_var;

Ответ 2

• Правильно, через Front Controller и маршрутизаторы
• Не совсем. Реализация Magento ViewModel частично облегчается тем, что представления (блоки) создают свои собственные модели.
• Да, через модели ресурсов.

Когда блоки обрабатываются с помощью типичного потока $this->loadLayout()->renderLayout() в контроллере действий, если они используют шаблоны, эти шаблоны include() d во время рендеринга.

После вызова renderLayout() выполнение все еще находится в области действия контроллера, к которому мы отправили, так что вы можете получить доступ к полученному отклику, получив объект запроса.

Ключевые сюжетные точки:

• index.php calls Mage::run()
• Mage::run вызывает Mage_Core_Model_App::run()

• App::run() вызывает Mage_Core_Controller_Varien_Front, сначала его метод init(), который собирает и устанавливает маршрутизаторы, а затем dispatch() выполняет следующие действия:

  а. URL-адрес базы данных переписывается

  б. Конфигурация перезаписывается (устарела)

  с. Совместите правильное действие контроллера через маршрутизатор. Выполнение переходит от Front Controller к контроллеру действия. Вызов блоков с использованием макета или вручную будет выполнять выполнение для блокировки классов и моделей и шаблонов, а затем мы (обычно) возвращаемся к действию контроллера.

  д. Отправка объекта ответа (с предположением, что он был изменен контроллером действия).

Если вы посмотрите на Mage_Core_Controller_Varien_Front::dispatch(); you'll see the call to $this- > getResponse() → sendResponse(); `, который будет вытолкнуть вывод, которому предшествует событие (controller_front_send_response_before), которое может быть использовано как крючок для добавления или управления любым ответом, связаны между собой.

Ответ 3

Нет, он оставляет контроллер (тот, который контролирует запрос), а затем переходит к представлениям, где он отображается. После того, как представление (блок [s]) выполнило запрос, по существу, закончилось (за исключением главным образом помощников URL-адресов, которые не имеют логики, о которых можно говорить, но иногда обрабатываются в контроллере после визуализации представления.), Если у вас нет какой-либо после этого запускается крючок.

Я использую эту блок-схему и эту серию (Alan Storm - это парень), чтобы узнать о маршрутизации запроса Magento.