One of the architectural goodies of Magento is it’s Singleton design pattern. In short, Singleton design pattern ensures a class has only one instance. Therefore one should provide a global point of access to that single instance of a class.

So why would you want to limit yourself to only one instance? Let’s say you have an application that utilizes database connection. Why would you create multiple instance of the same database connection object? What if you had references to an object in multiple places in your application? Wouldn’t you like to avoid the overhead of creating a new instance of that object for each reference? Then there is the case where you might want to pass the object’s state from one reference to another rather than always starting from an initial state.

Inside the Mage.php file of Magento system there is a getSingleton method (function if you prefer). Since it’s footprint is rather small, I’ll copy paste the code for you to see it.

public static function getSingleton($modelClass=”, array $arguments=array())
{
$registryKey = ‘_singleton/’.$modelClass;
if (!Mage::registry($registryKey)) {
Mage::register($registryKey, Mage::getModel($modelClass, $arguments));
}
return Mage::registry($registryKey);
}

First, notice the word static. In PHP and in other OOP languages keyword static stands for something like “this can be called on non objects, directly from class”. Now let me show you the footprint of the getModel method.

public static function getModel($modelClass=”, $arguments=array())
{
return Mage::getConfig()->getModelInstance($modelClass, $arguments);
}

Do you notice the parameters inside the brackets? They are the same for both of theme. Where am I getting with this? Well, I already showed you how to figure out the list of all of the available parameters in one of my previous articles on my site. So all we need to do at this point is, play with those parameters using getSingleton() method and observe the results.

Most important thing you need to remember is that using getSingleton you are calling already instantiated object. So if you get the empty array as a result, it means the object is empty. Only the blueprint is there, but nothing is loaded in it. We had the similar case using getModel(‘catalog/product‘) on some pages. If we done var_dump or print_r we could saw the return array was empty. Then we had to use the load method to load some data into our newly instantiated object.

What I’m trying to say, you need to play with it to get the feeling. Some models will return data rich objects some will return empty arrays. If we were to do Mage::getSingleton(‘catalog/session) on view.phtml file we would retrieve an array with some useful data in it. Do not get confused with me mentioning the view.phmtl file, it’s just he file i like to use to test the code. Using Mage::getSingleton(‘core/session) would retrieve us some more data. You get the picture. Test, test, test… What’s great about the whole thing is that naming in Magento is perfectly logical so most of the time you will probably find stuff you need in few minutes or so.

For the end here are some screenshots for you to see the results of calling getSingleton with catalog/product and catalog/session parametars.

Hope this will be useful for some of you.

Let’s have a look at the /app/design/frontend/default/default/template/catalog/product/view.phtml file. If you open this file and execute var_dump($this) your browser will return empty page after a short period of delay. By page I mean on the product view page; the one you see when you click on Magetno product. Experienced users will open PHP error log and notice the error message caused by var_dump(). Error message:
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 121374721 bytes)

I like using print_r() and var_dump(), mostly because so far I had no positive experience using fancy debug or any other debugger with systems like Magento.

Why is PHP throwing errors then? If you google out the error PHP has thrown at you, you’ll see that PHP 5.2 has memory limit. Follow the link http://www.php.net/manual/en/ini.core.php#ini.memory-limit to see how and what exactly.

Google search gave me some useful results trying to solve my problems. I found Krumo at http://krumo.sourceforge.net/. It’s a PHP debugging tool, replacement for print_r() and var_dump(). After setting up Krumo and running it on Magento it gave me exactly what I wanted. It gave me the object type of the dumped file; in this case it gave me object type of $this.

If you’re using an IDE studio with code completion support like NuSphere PhpED, ZendStudio or NetBeans and you decide to do something like $this-> you won’t get any methods listed. I haven’t yet seen the IDE that can perform this kind of smart logic and figure out the context of $this by it self.

What you can do is use the information obtained by krumo::dump($this). Performing krumo::dump($this) on /app/design/frontend/default/default/template/catalog/product/view.phtml file will return object type, Mage_Catalog_Block_Product_View.

Now if you do

Mage_Catalog_Block_Product_View::

your IDE supporting code completion will give you a drop down of all the available methods, let’s say canEmailToFriend();

Mage_Catalog_Block_Product_View::canEmailToFriend();

Now all you need to do is to replace  Mage_Catalog_Block_Product_View with $this like

$this->canEmailToFriend();

And you’re done. All of this may look like “why do I need this”. What you need it a smart IDE, one that can figure out the context of $this by it self and call the methods accordingly. No IDE currently does that, if I’m not missing on something. For now I see no better solution to retrieve the object context of $this across all those Magento files.

If you need some help setting up Krumo with Magento you can read my other, somewhat detailed article on activecodeline.com.

Hope this was useful for you.