I know how to override Mage classes (any class within app/code/core)
My question is how to override Varien classes? (classes within lib/Varien)
If I want to override Mage_Adminhtml_Block_Page_Menu
I create a class MyCompany_Adminhtml_Block_Page_Menu under app/code/local/MyCompany/Adminhtml/Block/Page/Menu.php
I name it like:
class MyCompany_Adminhtml_Block_Page_Menu extends Mage_Adminhtml_Block_Page_Menu
Now Magento uses my class MyCompany_Adminhtml_Block_Page_Menu instead of Mage_Adminhtml_Block_Page_Menu
My question is: where should I put the new class, and how to name it, to override, for example Varien_Date (lib/Varien/Date.php)
Thanks
If you must, copy the file and path to the local codepool and make the necessary changes. There is no configuration mapping to change the class name.
Explanation: see the bootstrapping in app/Mage.php. There is a load order set for the codepools and libraries in the following order:
app/code/local/
app/code/community/
app/code/core/
lib/
Typically, Varien_Autoload is responsible for mapping classnames such as Varien_Data_Collection_Db, Mage_Core_Model_Abstract, or Zend_Db_Select to relative filenames (Varien/Data/Collection/Db.php, Mage/Core/Model/Abstract.php, and Zend/Db/Select.php respectively). These file locations are then passed to include(), which internally uses the load order set in the bootstrap. Therefore, if the file Varien/Data/Collection/Db.php is present under one of the "earlier" locations, that version of the class definition will be used.
These type of modifications may be justified, but they should be well-considered and documented, as the entire definition will be owned by you and any upgrades will need to be merged in the future. It would be good to know what you would like to change, as someone else may have a slightly less invasive option.
Related
I've got a small problem (maybe it isnt even a problem)
I am making an application in Ruby, and the folder/file structure goes something like this:
OrderSet/
..item.rb
..file.rb
..order_object.rb
OrderGet/
..item.rb
..files.rb
..order.rb
As you can see I got two item.rb files, they are both different in class structure. Now I need to create an OrderSet/item.rb object, how do I specify it needs to look in OrderSet and does not get the OrderGet one?
I have to make clear, all files are required in the main rb file.
I have tried doing OrderSet.Item (the class is called Item inside the item.rb) but it complains about an ininitialized constant OrderSet
Thanks in advance!
[edit]
I have also tried to make modules out of it, maybe I don't understand the concept correctly, but I have tried it with OrderSet.Item.new (OrderSet as module name)
You could use a module to create a namespace - that way each set of classes would be encapsulated to what they do (the folder name from your example). So classes in OrderSet would be wrapped in a module for example OrderSet/item.rb would become:
module OrderSet
class Item
# methods and properties
end
end
Then you could use it like
new_order_set = OrderSet::Item.new
RubyMonk has a lesson called Modules As Namespaces which has more details and examples you can run in your browser.
As title suggest i want to override Mage_Payment_Model_Method_Abstract class , I know that it is abstract class. and we can easily override abstract class using local directory like app\code\local\Mage\Payment\Model\Method\Abstract.php. But i want to know is there any other option for me ? Because this option is not safe with different magento version.
Any help will be appreciated.
Thank you
'Override' is a method where you copy a class from the Magento core into the local code. For ex:
app/code/core/Mage/Rule/Model/Abstract.php
to
app/code/local/Mage/Rule/Model/Abstract.php
An override is where you tell Magento to "Use this class file instead of the other class file". Similar, but different from a rewrite. Rewrites are considered better practice because they're less likely to cause problems with upgrades and extension compatibility.
An abstract class is never instantiated, it can never be rewritten.
If you override, you need to take care of future upgrades. You can't rewrite an abstract class. The rewrite system works because Magento uses a factory pattern to instantiate model, blocks, and helpers.
The other alternative is to use a traditional class override. For ex: Copy
app/code/core/Mage/Rule/Model/Abstract.php
to
app/code/local/Mage/Rule/Model/Abstract.php
Also somewhere on the blog I read this (not in favor though) For ex: Copy
Mage_Shipping_Model_Carrier_Abstract
from
app/code/core/Mage/Shipping/Model/Carrier
to
app/code/local/Mage/Shipping/Model/Carrier
Do NOT change the class name, just change or add the methods as you need.
This is a trick. Magento loads a class from several locations, and app/code/local comes before app/code/core
Good luck!!!
/libraries/joomla/application/component/controller.php
where this file is located in JOOMLA 3.1.5
In 3.0, it is my understanding that most of the classes autoload, so you can typically guess a files location based on the class name (since this is how the autoloader finds them!). Basically, the prefix is mapped to one or more libraries, and then each word after that represents a folder or file (for the last word of the class). If there is just a prefix and one word (like JController), controller will be both the folder and file name. Tricky? Some examples:
For these, you should note that the J prefix is mapped to several libraries: joomla, cms, and legacy.
JControllerLegacy will be defined in either libraries/joomla/controller/legacy.php, libraries/cms/controller/legacy.php, or libraries/legacy/controller/legacy.php. In this case it is the last one, the legacy library.
JController no longer refers to a class but an interface in 3.1, but still it will reside at either libraries/joomla/controller/controller.php, libraries/cms/controller/controller.php, or libraries/legacy/controller/controller.php. In this case it happens to be the first place, the joomla library.
Note in the above how controller is repeated as both the folder and the file name. They don't allow php files in the main library folder (ie. you can't do libraries/joomla/controller.php, so for short class names, you will see the name doubled.)
Finally, any class that follows this format will be autoloaded by joomla, so there is no need to include a jimport call before using the class.
Is both term override and rewrite are same in Magento. I have searched alot for this but not found any answer.
Thanks
Short answer: yes, though it depends on who you talk to.
All rewrites are overrides, but not all overrides are rewrites. A rewrite in Magento should only refer to a configuration-based class overrides. Factory methods are used by the framework to instantiate the MVC types:
Mage_Core_Model_Layout->createBlock()
Mage::helper()
Mage::getModel()
Mage::getResourceModel()
etc....
These methods generally match a class group (e.g. catalog) to a class prefix (e.g. Mage_Catalog_Model) in order to instantiate a particular class (e.g. Mage::getModel('catalog/product') yields Mage_Catalog_Model_Product). This mapping allows for developers to specify a certain xpath associated with the class argument (e.g. 'catalog/product' & global/models/catalog/rewrite/product) to specify an alternate class to instantiate. From there it's the responsibility of the developer to use inheritance as appropriate to achieve the proper overriding & extending behavior.
There are other mechanisms for achieving overrides, the most common of which is the so-called "include path hack", which allows for classes from "lower" autoload directories to be (re)defined in higher-level directories in the following order of precedence (note that app/code/local/):
app/code/community/
app/code/core/
lib/
This style of override should be considered a last-case means of changing core code. It has legitimate use cases (especially for obeying DRY), but may be non-obvious in an upgrade.
Many extensions (including the one's I've written) include a helper class that just extend the abstract base class without adding any functionality. The helper usually looks like this:
class MyCompany_MyModule_Helper_Data extends Mage_Core_Helper_Abstract {
}
The extended class is therefore just used for things that the abstract class provides, especially for translations. On the other hand, all Block and Controller classes in Magento inherit the __() method for translations - and in an extension I'm currently developing I don't have the need to call the helper class even once.
Can I just delete the helper class and remove it from config.xml? I've tried it and the extension seems to work fine without, but due to Magento's complexity I'm always a bit worried that there are implications I'm not aware of.
If you're creating a module from scratch, helper classes aren't strictly necessary. I usually skip creating one until it's needed.
However, if any XML file uses the module attribute to specify a translation module, that attribute needs to resolve to a valid helper. For example, in this core file
<!-- File: app/code/core/Mage/Catalog/etc/system.xml -->
<tabs>
<catalog translate="label" module="catalog">
<label>Catalog</label>
<sort_order>200</sort_order>
</catalog>
</tabs>
There's module="catalog". By specifying this attribute, the Magento system code that translates the label will look something like this
Mage::helper('catalog')->__('Label');
So, removing the helper from the catalog module would break parts of Magento.
(The single part class alias catalog is automatically converted to Mage::helper('catalog/data') by Magento system code)
This "helper to group translations" feature is used in many of Magento's XML files, not just system.xml (layout, widgets, etc.). Additionally, there are some systems in Magento that will infer and/or require the existence of a helper module for translations (Access Control, external API system,etc. )
Long Story Short: If you're creating a module from scratch, feel free to leave the helper out until you start getting errors that Magento can't instantiate a helper. Never remove an existing helper from a module, and if you want to make sure you're 100% compatible with assumptions other people might make, always include a Data.php helper class.
Magento's Helper classes contain utility methods that will allow you to perform common tasks on objects and variables. http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-1-introduction-to-magento#6
Assuming that the Helper file is empty with no custom methods eg.
<?php
class MagePal_SomeModule_Helper_Data extends Mage_Core_Helper_Abstract
{
}
Then some of things that may still be affected are:
system.xml - blank screen for your module in admin -> system -> config
$this->__('') - error in your .phtml template (for internationalization/translation)
So if your helper is empty, without a system config section and no translation then it 'maybe' ok to delete.