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.
Related
When I generate code from StructureDefinitions, it would be obvious to use the class for the resource referenced in base as superclass.
A resource that is based on another resource can change the the type of a property of the base resource (for example from String to List<String> if max="0" is overridden by max="*").
This would break in strongly typed languages because a subclass has to conform to the interface of the super class (can only specialize but not generalize).
What would be the correct strategy to deal with that?
I can use snapshot instead of differential and not extend the class of the base resource.
Should I still extend one of the more general super classes like Element, BackboneElement, Resource, DomainResource?
Are there any flaws in my reasoning?
Resources can't "extend" other resources. If the base resource has a cardinality for an element of 1..1, the derived model can't change the lower cardinality below 1, nor the upper cardinality above 1.
The primary way of "extending" a resource is to make use of the "extension" element which is defined as being 0..* pretty much everywhere in the base resources. So technically when you're creating a profile, you're always constraining - either tightening down core elements or constraining expectations for at least some of the repetitions of the "extension" element.
You can find more information about allowed cardinality changes here
I am talking about concern/module/extensions as they exist in Ruby and Swift for example.
A Ruby module is something that a class can include (= add the module functions as its own instance methods) or extend (add the module functions as its own class methods).
A swift extension is also an add-on for class, typically when you want to add a functionality you would first define the prototype, then implement it in an extension.
(please correct me if I'm wrong)
How would you represent such a Ruby module/Swift extension in UML, and its link to the class it is included in/it extends ?
I also don't know a standard for this, but would model it like this:
A Realize relation with an <<import>> stereotype. Maybe the Realize is too strong in the context and a simple Dependency but still with that stereotype would be better.
Not everything is available natively in UML. But like in any language, if you don't have a single word for a thing you can make constructs that describe the thing. You are rather free in choosing your vocabulary. Only you should be consistent in the domain where you use such a paraphrase.
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!!!
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.
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.