Skip to main content
add catalog/image example
Source Link
Fabian Schmengler
  • 66.1k
  • 25
  • 188
  • 422
  • __() translation method: To get a translation of a specific module, you should use Mage::helper('module-alias')->__('string to be translated'). This happens implicitly if you use $this->__(...) within a template or block and if you use the translate="..." attribute in XML files
  • Mage::helper('core') methods: localized date, price and currency formating, escaping and encoding data
  • Mage::helper('tax') methods to get information from the tax configuration and calculate prices based on that
  • Mage::helper('catalog/image') provides an interface to create cached and resized catalog images and retrieve their URL
  • Mage::helper('catalog/product_url_rewrite')->joinTableToSelect() joins the URL rewrite table to a product collection query.

But as always Magento breaks its own unwritten rules and should not be taken as an example. A "good" example how to not use helpers is Mage_Catalog_Helper_Product_Compare which has an $_itemCollection property that can only be initialized once and a $_customerId property that can be changed with a setter. You will find a few more helpers related to the catalog with attached collections. Writing tests for code that uses them or re-use them in different context is not fun, so please don't do that at home.

The catalog/image helper mentioned above is another example of a helper that really should not be a helper. You need to pass a product with init() first which resets its current state, then you set various parameters (like resize(), setQuality()) and in the end you can get the URL with its __toString() method. That looks nice when used in a template but the code is a huge mess and it doesn't make sense as a singleton.

  • __() translation method: To get a translation of a specific module, you should use Mage::helper('module-alias')->__('string to be translated'). This happens implicitly if you use $this->__(...) within a template or block and if you use the translate="..." attribute in XML files
  • Mage::helper('core') methods: localized date, price and currency formating, escaping and encoding data
  • Mage::helper('tax') methods to get information from the tax configuration and calculate prices based on that
  • Mage::helper('catalog/product_url_rewrite')->joinTableToSelect() joins the URL rewrite table to a product collection query.

But as always Magento breaks its own unwritten rules and should not be taken as an example. A "good" example how to not use helpers is Mage_Catalog_Helper_Product_Compare which has an $_itemCollection property that can only be initialized once and a $_customerId property that can be changed with a setter. You will find a few more helpers related to the catalog with attached collections. Writing tests for code that uses them or re-use them in different context is not fun, so please don't do that at home.

  • __() translation method: To get a translation of a specific module, you should use Mage::helper('module-alias')->__('string to be translated'). This happens implicitly if you use $this->__(...) within a template or block and if you use the translate="..." attribute in XML files
  • Mage::helper('core') methods: localized date, price and currency formating, escaping and encoding data
  • Mage::helper('tax') methods to get information from the tax configuration and calculate prices based on that
  • Mage::helper('catalog/image') provides an interface to create cached and resized catalog images and retrieve their URL
  • Mage::helper('catalog/product_url_rewrite')->joinTableToSelect() joins the URL rewrite table to a product collection query.

But as always Magento breaks its own unwritten rules and should not be taken as an example. A "good" example how to not use helpers is Mage_Catalog_Helper_Product_Compare which has an $_itemCollection property that can only be initialized once and a $_customerId property that can be changed with a setter. You will find a few more helpers related to the catalog with attached collections. Writing tests for code that uses them or re-use them in different context is not fun, so please don't do that at home.

The catalog/image helper mentioned above is another example of a helper that really should not be a helper. You need to pass a product with init() first which resets its current state, then you set various parameters (like resize(), setQuality()) and in the end you can get the URL with its __toString() method. That looks nice when used in a template but the code is a huge mess and it doesn't make sense as a singleton.

Source Link
Fabian Schmengler
  • 66.1k
  • 25
  • 188
  • 422

The question has two aspects:

  1. Should I write my own helpers and what for?
  2. Should I use the core helpers and what for?

1. Writing helpers

In general, having classes named Helper, Util or similar just says "I have some functions that I don't know where to put" and don't make much sense as a class.

Magento instantiates helpers as singletons and most of the core helpers don't have any state, so the methods could as well be static or even functions without a class. All of this is often considered a code smell, a flaw in the application design.

As Marius already pointed out, you don't need to use helpers for your own code. Just create a default empty helper per module if you use module specific translations, otherwise they won't work. Prefer models (which do not need to extend Mage_Core_Model_Abstract if they don't represent database data) or independent library classes.

However, I would not be too strict about "not using helpers at all" and instead use them for query shortcuts like:

  • access module configuration:

      public function getFooBar() 
      {
          return Mage::getStoreConfig('module/foo/bar');
      }
    
  • factory methods for library classes

      public function getNewFooService()
      {
          return new \Foo\Service(...);
      }
    

You could find other places but IMHO, the module helper is often good enough for things like that.


##2. Using helpers Consuming the core helpers is something you will do quite often.

Examples:

  • __() translation method: To get a translation of a specific module, you should use Mage::helper('module-alias')->__('string to be translated'). This happens implicitly if you use $this->__(...) within a template or block and if you use the translate="..." attribute in XML files
  • Mage::helper('core') methods: localized date, price and currency formating, escaping and encoding data
  • Mage::helper('tax') methods to get information from the tax configuration and calculate prices based on that
  • Mage::helper('catalog/product_url_rewrite')->joinTableToSelect() joins the URL rewrite table to a product collection query.

There are many more (more or less) useful functions hidden in the core helpers, if you need a specific functionality that is likely to be used in the core somewhere, check if you can reuse a helper method.

Usually these helpers are stateless objects and the methods are query methods (i.e. they have no side effects)

But as always Magento breaks its own unwritten rules and should not be taken as an example. A "good" example how to not use helpers is Mage_Catalog_Helper_Product_Compare which has an $_itemCollection property that can only be initialized once and a $_customerId property that can be changed with a setter. You will find a few more helpers related to the catalog with attached collections. Writing tests for code that uses them or re-use them in different context is not fun, so please don't do that at home.


TL;DR:

  • The core helpers contain useful tools.
  • You need helpers for translation
  • Helpers should be stateless
  • In your own modules, avoid using helpers as assorted function collections. In most cases you can find a more appropiate place