Sunday, 22 August 2010
Moving Data around in Magento
Controller to view
Like we have seen previously that blocks are separate from the main controller which contains all the data for the view. This helps to reduce coupling of modules and sub modules. Therefore if we supply the block with values it is directly available in the view. Following is an example code snippet on how sending data from main controller to templates / blocks works:
$layout = $this->getLayout();
$block = $layout->getBlock('b'); <-- block name b usually given as <modulename> / <block name>
$block->setData('variable_name', $value);
$block->setData('variable_2', $value2);
and so on...
and from the template or block simply $this->getData('variable_name'); helps fetch the value.
Global
If you like to set data which should be available from any module and any module components like model / view / controllers then simply set the data using Magento register / registry as follows:
Set: Mage::register('variable_name', 'data');
Get: Mage::registry('variable_name');
Session
To move data around session:
Get variable: Mage::getSingleton('core/session')->getData('variable_name');
Set variable: Mage::getSingleton('core/session')->setData('variable_name', 'value');
Set variable: Mage::getSingleton('core/session')->setData('variable_name', $value);
Parameter Passing
Like we always need to send data from views (from some form) back to some controllers for processing or saving data we always need Get or Set and in Magento its simpler to do:
Get / Post Data from form(array): $params = $this->getRequest()->getParams();
Data: $params['param_name'];
Monday, 16 August 2010
Running a DB Query
If you want to run a raw query from your magento module it is possible using the following codes:
Open db connections
Read connection : $db = mage::getSingleton('core/resource')->getConnection('core_read'); Write connection : $db = mage::getSingleton('core/resource')->getConnection('core_write'); Execute your query given in $query
Run Query: $db->query($query); Finally fetch results:
Fetch Results (array): $db->fetch();
Read connection : $db = mage::getSingleton('core/resource')->getConnection('core_read'); Write connection : $db = mage::getSingleton('core/resource')->getConnection('core_write'); Execute your query given in $query
Run Query: $db->query($query); Finally fetch results:
Fetch Results (array): $db->fetch();
Saturday, 14 August 2010
Resources to start-off
The following is a list of resources for starting off with Magento
- The first is a very good start up tutorial by Alan storm.
- Second most important is Magento Class Documentations (unfortunately the Magento site documentation is not that helpful) but I find this site useful.
- In order to create (simple) modules for start, using this online script is helpful and useful.
- Or Download Module Creator to create modules from your Magento installation
- If you are confused about how to install extensions:
1. Get to the Magento Connect site to get your extension. You will be given an extension key.
2. Goto Magento http://<yoursiteshost>/downloader and paste your key... that should do!
Magento Architecture
Magento's architecture does follows the well known MVC architecture but it actually does have some of its own additions which do help large scale web developments. Like we all know MVCs (Model, View and Controller) architecture is where you have a set of modules which comes with Models, Views and Controllers to split up your codes and make code management easier and simpler.
In the conventional MVC, one would request the controller for a service and the controller would use models to get processed data and put forward the data to the view to give user the response and take another request which would be carried out in the same fashion. The conventional MVC works as illustrated below.
Magento's architecture has added a lot more sub blocks to the above MVC architecture in order to handle bigger e-commerce system which can handle multiple sites / stores from the same back-end. Magento Architecture Views itself is broken into 3 parts, the model into 2 and you have controllers and helpers where helpers are module specific.
If you are thinking that why helpers are module specific then you should know that Magento helpers and in fact all the models and controllers extends Magento core controllers, models and helpers so the common features are there in the super class whereas you can also add module specific features which you need not share to make big helper classes.
To start off lets see the image below.
We can see that Views have been split into three parts. The templates are the plainly html codes usually saved as phtmls with php tags to prints data and do some basic loops and some javascript calls like our usual view would look like. Next comes blocks which is a new concept to MVC. Blocks are simply used to lower the burden on central controller and make different views in a module more independent. This is important these days and any websites these days stands on a number of different blocks and some blocks may be AJAX loaded and provide different services. Therefore, Views have their own controllers to ask or request processed data from Models and provide graphical 'view' through templates. Blocks holds all the data and functions that can be called from the view template and Block can have nested blocks. Therefore, our website will have a root block, a header block, a navigation block and contents and footer block therefore they can be nested like that. Now, we might wonder what is the role of the central controller if every view comes with their own controller which can interact with models and helpers.
That is where layout comes into play actually. In most of the definitions I read previously they say that in order to say which blocks goes with which template and in order to define which block is nested in which we need the layout. This is true but there is a little bit more to it. Layouts can only be called by a central controller name, therefore the central controller has the layout which defines the sub controllers (blocks) and the templates it contains. The central controller along with the helper provide service to the overall block set while the individual blocks provide service in email. Layout therefore simply provides a way to tell which is the super block and which are nested and how they are nested.
Finally, Models contains Models ofcourse and collections. Models works as a service it provides functionalities for various business calculations and data processing, whereas, the collection is used to provide functions to retrieve the Data.
Magento's architecture has added a lot more sub blocks to the above MVC architecture in order to handle bigger e-commerce system which can handle multiple sites / stores from the same back-end. Magento Architecture Views itself is broken into 3 parts, the model into 2 and you have controllers and helpers where helpers are module specific.
If you are thinking that why helpers are module specific then you should know that Magento helpers and in fact all the models and controllers extends Magento core controllers, models and helpers so the common features are there in the super class whereas you can also add module specific features which you need not share to make big helper classes.
To start off lets see the image below.
We can see that Views have been split into three parts. The templates are the plainly html codes usually saved as phtmls with php tags to prints data and do some basic loops and some javascript calls like our usual view would look like. Next comes blocks which is a new concept to MVC. Blocks are simply used to lower the burden on central controller and make different views in a module more independent. This is important these days and any websites these days stands on a number of different blocks and some blocks may be AJAX loaded and provide different services. Therefore, Views have their own controllers to ask or request processed data from Models and provide graphical 'view' through templates. Blocks holds all the data and functions that can be called from the view template and Block can have nested blocks. Therefore, our website will have a root block, a header block, a navigation block and contents and footer block therefore they can be nested like that. Now, we might wonder what is the role of the central controller if every view comes with their own controller which can interact with models and helpers.
That is where layout comes into play actually. In most of the definitions I read previously they say that in order to say which blocks goes with which template and in order to define which block is nested in which we need the layout. This is true but there is a little bit more to it. Layouts can only be called by a central controller name, therefore the central controller has the layout which defines the sub controllers (blocks) and the templates it contains. The central controller along with the helper provide service to the overall block set while the individual blocks provide service in email. Layout therefore simply provides a way to tell which is the super block and which are nested and how they are nested.
Finally, Models contains Models ofcourse and collections. Models works as a service it provides functionalities for various business calculations and data processing, whereas, the collection is used to provide functions to retrieve the Data.
Subscribe to:
Posts (Atom)