Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

In Magento, how do Blocks Grab Data from Models?

Can someone please explain this?

Let me tell you what i know. If the first three points are good, please explain the 4 point.

  1. Request come to controller.
  2. In Controller Action we initiate Models.
  3. Models collects or generates all the information needed by connecting to database etc.

What happens after that?

  1. How do models transfer data to Blocks, or do Blocks get data from models?

  2. Templates get the prepared data and show on the screen

    • Also, does the request ever goes back to controller again?

Please explain. I'm confused at several places.

like image 826
Ricky Sharma Avatar asked Mar 19 '12 01:03

Ricky Sharma


People also ask

What is the use of block in Magento 2?

Magento block is a modular unit of content that can be placed anywhere on the page. Blocks in Magento are referred to as static blocks or CMS blocks. They help to display fixed information such as text, images, and embedded video, as well as dynamic information from a widget that originates through the database.

How do I edit blocks in Magento 2?

Navigate to Content > Pages, choose the CMS page you want to display the CMS block on and in the Action section choose Edit. 2. Unfold the Content section and press the Widget button to insert the widget. Set the CMS Static Block as the Widget Type to continue.


2 Answers

Nothing transfers data to the blocks. After a controller action has done its model interacting, it's responsible for

  1. Loading a layout object (which, indirectly, loads and creates block objects)

  2. Tell that layout object to render a page.

Most Magento controller actions do this with two calls at the end of a controller action.

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

In Magento, nothing sets data on the view. Instead, the view (that is, the block objects) ask the system for data. You can see an example of this in the Mage_Tag_Block_Customer_View block class.

#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;
}    
...

Here, this block's getTagInfo method asks the model directly for its information. This way, the front-end template developer has access to a

$this->getTagInfo();

method. I also have it on good authority that a block's _prepareLayout method is the perfect place to put most, if not all, of your data fetching code in a block.

A second pattern you'll see used is the Magento registry pattern. This is a Magento system that lets you set a system-wide (but not PHP) global variable.

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

Sometimes a Magento developer will use the registry to set a variable up in a controller action, and then grab is back out in the blocks. For example, in the admin console's invoice controller.

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

and then a Block will reference it later.

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

I'm not wild about the registry pattern, but it's used by the core team, so it's probably kosher.

Finally, if you're looking to emulate the "dumb view" pattern used in most PHP MVC frameworks, try something like this

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

and then in the block and/or template file.

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

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

After you call loadLayout, Magento will have created all the block objects. What you're doing above is getting reference to a specific block object, and then setting its data.

Per Vinai's comments below, there's also a block's assign method to consider.

Similar to setData, after calling loadLayout (or from a block's _prepareLayout) method, you can do something like

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

and then in your block's phtml file, you'd be able to output that view variable

echo $my_view_var;
like image 157
Alan Storm Avatar answered Oct 29 '22 14:10

Alan Storm


  1. Correct, via the Front Controller and routers
  2. Not quite. Magento's ViewModel implementation is facilitated in part by having the views (Blocks) instantiate their own models.
  3. Yes, through resource models.

When blocks are rendered via the typical $this->loadLayout()->renderLayout() flow in the action controller, if they use templates, those templates are include()d at render time.

After a renderLayout() call, execution is still in the scope of the controller action we've dispatched to, so you can access the rendered response by getting the request object.

Key plot points:

  1. index.php calls Mage::run()
  2. Mage::run calls Mage_Core_Model_App::run()
  3. App::run() calls Mage_Core_Controller_Varien_Front, first its init() method which gathers and sets up routers, then dispatch() which does the following:

    a. Database URL rewrites

    b. Configuration rewrites (deprecated)

    c. Match the correct controller action via the router. Execution jumps from Front Controller to action controller. Invoking blocks using layout or manually will then pass execution to block classes and models and templates, and then we (normally) return to the controller action.

    d. Sending the response object (with the assumption that it's been altered by an action controller).

If you look at Mage_Core_Controller_Varien_Front::dispatch(); you'll see the call to$this->getResponse()->sendResponse();` which will flush output, preceded by an event (controller_front_send_response_before) which can be used as a hook to add or manipulate anything response-related.

like image 29
benmarks Avatar answered Oct 29 '22 14:10

benmarks