The core resource model has a method to get you any table name for any model in
the system. Table names do not have to follow the name of the model, an end-user
can change the table names by changing an XML setting. Also, any installation can
have an arbitrary prefix for any table. Therefore, it is best to use the getTable method
of the core resource.
$r = Mage::getResourceSingleton(’core/resource’)->getConnection(’core_read’)
$tableName = $r->getTable(’catalog/product’);
$tableName === ’catalog_product_entity’;
This happens because we have the following XML configuration in the catalog mod-
ule’s config file.
...
How do I show Magento products on a non-Magento page?
This is an often requested feature. There are a number of ways to do it too. You
could create a listener to publish a category of products to static HTML whenever a
category changes. You could run a cron script or other scheduled task to run some
Magento code to export a category of products to a static file as well. The quickest
way to get the job done is to simply include the necessary Magento files in your other
PHP script and call the display logic.
Start with the basic shell magento script.
require_once ’/path/to/app/Mage.php;
umask(0);
//not Mage::run();
Mage::app(’default’);
Assuming we want to display an entire category of products, we need to load up the
category display block and render it. This will load the products and push the data
through the associated template file.
//code snipped
$className = Mage::getConfig()
->getBlockClassName(’catalog/product_list’);
$block = new $className();
$className = Mage::getConfig()
->getBlockClassName(’core/template’);
$toolbar = new $className();
$block->setChild(’toolbar’, $toolbar);
//choose whatever category ID you want
$block->setCategoryId(3);
$block->setTemplate(’catalog/product/list.phtml’);
echo $block->renderView();
You might think that we would be using the category view block for this task, but
we’re not. The product list block is the component which does the actual printing of
the products. The category view block does too much work preparing the rest of the
page and is too integrated into Magento to cleanly use outside of Magento’s code.
The reason that we make a core/template type block and call it “toolbar” is be-
cause the template file for the product list wants to show the output from a block
called toolbar. If we set the real toolbar (type catalog/product_list_toolbar) then
we start unraveling a whole lot of Magento dependencies, as the toolbar requires a
product collection. This is the simplest, quickest way to render a category of prod-
ucts “outside” Magento.
How do I use installation and upgrade files in my custom mod-
ules?
Magento automatically installs or upgrades any module that it en-
counters during runtime. The installation files are located under
_setup/mysql4-install-X.Y.Z.php. The trigger for
YourModule/sql/yourmodule
running this file is that your module’s version number is not present in the DB
table core_resource and that you have defined a version number in your module’s
etc/config.xml file. You will also need to define a global resource for your module’s
setup, use a tag name of
includes both setup module and a connection, the installation or upgrade will not
perform, even if you increase the version number.
etc/config.xml contents...
Given that XML file, and an absence of any record containing company_yourmodule in
table core_resource, your module’s install file will be run the next time that module
is executed.
Once installed, upgrades can be triggered when you change the version number
in the XML configuration file to be greater than the value in core_resource. This will
trigger a succession of any mysql4-upgrade-X.Y.Z.php file that has a version number
greater than the number found in the core_resource table.
The syntax of these installation files looks like this:
$installer = $this;
/* @var $installer Mage_Catalog_Model_Resource_Eav_Mysql4_Setup */
$installer->startSetup();
$installer->run("
ALL YOUR SQL IN ONE STRING (the system breaks apart the SQL by semi-colon);
USE ’{$installer->getTable(’my_own_table’)}’ TO KEEP TABLE PREFIXES
CONSISTENT;
");
$installer->endSetup();
/*
$installer->installEntities(); //only needed if you are installing
new entities and they are defined properly
*/
//any other setup code such as inserting default data, caching data, etc.
No comments:
Post a Comment