config.xml

<?xml version="1.0" encoding="UTF-8"?>

<!--

This file is merged together out of many XML files. Those files are loaded in alphabetical order taking
module dependencies into account.

TODO: describe other global files and their load order

Access configuration values:
TODO: provide examples
- $store->getConfig($path);
- Mage::getStoreConfig($path [, $store]);
- Mage::getStoreConfigFlag($path [, $store]);
- (Accessing by absolute path) Mage::getConfig()->getNode($path [, $store]);

-->

<config><!-- Root node -->

	<modules><!-- Contains modules declarations (names, statuses, dependencies) -->

		<Foo_Bar>
		<!--
			This is the module name. "Foo" is the namespace and "Bar" is the actual module name
			Namespace and module name need to match the folder names in the code configured code pool
		-->

			<active>true</active>
			<codePool>community</codePool>
			<!--
				Code pool can be one of "local", "community", "core"
			-->

			<!--
				config/modules/Foo_Bar/active
				and config/modules/Foo_Bar/codePool is the minimum information Magento needs
				to find the config.xml inside your module. While all other stuff is configured
				in app/code/community/Foo/Bar/etc/config.xml this information is to be defined
				in app/etc/modules/Foo_Bar.xml
			-->

			<version>0.1.0</version>
			<!--
				This version number will be stored in core_resources after the module has
				been installed successfully. Based on this version number and the version number
				in the database tables this upgrade scripts will be executed.
			-->

			<depends>
				<!--
					Configure dependicies to other modules here. Those dependencies will be taken into account
					for the order of loading the modules
					Mage_Core will be always loaded first.
				-->

				<Mage_Customer />
				<Mage_Checkeout />
			</depends>
		</Foo_Bar>
	</modules>

	<global>
		<!-- Contains definitions that should be shared between all scopes -->

		<!--
			TODO: provide concrete examples
		 	- Main database settings
		 	- Connection types
		 	- Database adapters
		 	- Core modules class names
		-->

		<models>
			<!--
				"foobar" is the so called class group. You can choose it freely and it is used
				to instanciate classes later. Best practice is to use the module name in lowercase letters.
				Same for blocks and helpers.

				Example:
				Mage::getModel('foobar/example');

				Singleton:
				Mage::getSingleton('foobar/example');
			-->
			<foobar>
				<class>Foo_Bar_Model</class>
				<!-- This is the prefix that will substiture the classgroup when accessing a model -->

				<resourceModel>foobar_resource</resourceModel>
				<!--
					The resource model points to another classgroup that is used to load the corresponding resource model

					By convention the suffix of the resource model classgroup is "_resource".
				-->

				<rewrite>
					<example>Bar_Foo_Model_Example</example>
					<!--
						Rewrite class Foo_Bar_Model_Example with class Bar_Foo_Model_Example.
						Rewrite usually are done in other modules to extend or change the behaviour of the original class.
						In this example module "Bar_Foo" would override "Foo_Bar's" class "example".

						Rewrites must be configured in the original class group namespace.

						Xpath: config/global/models/<classgroup>/rewrite/<classname>: new classname

						Hint: Override classnames are always normal php class names. Magento's classgroup syntax is not
						supported here.
					-->
				</rewrite>

			</foobar>

			<foobar_resource>
				<!-- This resource model is configured to be used in config/global/models/foobar/resourceModel -->

				<!--
					Example:
					Mage::getResourceModel('foobar/example'[, $args]);

					Singleton:
					Mage::getResourceSingleton('foobar/example'[, $args]);
					note: $args will be ignored if the object was instantiated before and will be delievered from the registry instead
				-->

				<!-- A resource model basically is a normal model with all features of a model -->
				<class>Foo_Bar_Model_Resource</class>
				<!--
					Example:
					Mage::getResourceModel('foobar/example') will do a lookup at config/global/models/foobar/resourceModel
					and will call Mage::getModel('foobar_resource/example') then and use this as a resource model.
					"foobar_resource/model" will be resolved to Foo_Bar_Model_Resource_Example (unless rewritten)
				-->
				<deprecatedNode>foobar_mysql4</deprecatedNode>
				<!--

					Backwards compatibility for pre-MMDB extensions.
					In MMDB release resource nodes <..._mysql4> were renamed to <..._resource>. So <deprecatedNode> is left
					to keep name of previously used nodes, that still may be used by non-updated extensions

					@see Mage_Core_Model_Config::getGroupedClassName()
					@see Mage_Core_Model_Resource::getEntity($model, $entity)
				-->

				<entities>
					<exampletable><!-- Entity name -->
						<table>foobar_example</table>
						<!-- This points to a concrete table name -->
					</exampletable>
				</entities>
				<!--
					Mage::getResourceModel('foobar/example')->getTable('foobar/exampletable'); will return foobar_example
				-->

				<rewrite>
					<example>Bar_Foo_Model_Resource_Example</example>
					<!--
						Resource models can alse be rewritten. Also check config/global/models/foobar/rewrite
						for more information on rewrites.

						Hint: while rewriting a resource model like this will only affect the resource model
						of the given class you can change the resource models for the complete module by changing/overwriting
						the value in config/global/models/foobar/resourceModel
					-->
				</rewrite>

			</foobar_resource>

		</models>

		<blocks>
			<foobar>
				<class>Foo_Bar_Block</class>

				<rewrite>
					<example>Bar_Foo_Block_Example</example>
					<!--
						Will rewrite Foo_Bar_Block_Example to Bar_Foo_Block_Example.

						I.e. Mage::app()->getLayout()->createBlock('foobar/example') will return an instance of Bar_Foo_Block_Example
						instead of Foo_Bar_Block_Example

						Also check config/global/models/foobar/rewrite for more information on rewrites.
					-->
				</rewrite>

			</foobar>
		</blocks>

		<helpers>
			<foobar>
				<class>Foo_Bar_Helper</class>

				<rewrite>
					<example>Bar_Foo_Helper_Example</example>
					<!--
						Will rewrite Foo_Bar_Helper_Example to Bar_Foo_Helper_Example.

						I.e. Mage::helper('foobar/example') will return an instance of Bar_Foo_Helper_Example
						instead of Foo_Bar_Helper_Example

						Also check config/global/models/foobar/rewrite for more information on rewrites.
					-->
				</rewrite>

			</foobar>
		</helpers>

		<resources>

			<db>
				<!--
					Usually defined in app/etc/local.xml
					Contains the instance specific prefix that is used to access all tables
					Empty by default

					@see Mage_Core_Model_Config->getTablePrefix()
				-->
				<table_prefix></table_prefix>
			</db>

			<!--
			 	Database configuration:

			 	default_setup is configured in app/etc/local.xml

			 	@see Mage_Core_Model_Config->getResourceConfig($name)
			-->
			<default_setup>
				<connection>
					<host><![CDATA[localhost]]></host>
					<username><![CDATA[magento]]></username>
					<password><![CDATA[secret]]></password>
					<dbname><![CDATA[magento]]></dbname>
					<initStatements><![CDATA[SET NAMES utf8]]></initStatements>
					<!--
						Since Magento 1.6 this is configurable.
						This is the prefix used for install/upgrade scripts

						@see Mage_Core_Model_Resource_Setup::_getAvailableDbFiles()
						TODO: what models are available?
					-->
					<model><![CDATA[mysql4]]></model>
					<!-- TODO: what types are available? -->
					<type><![CDATA[pdo_mysql]]></type>
					<!-- TODO: what is the pdoType? -->
					<pdoType><![CDATA[]]></pdoType>
					<active>1</active>
				</connection>
			</default_setup>


			<!--
				But there are some more database handles configured in app/etc/config.xml
				that by default all reference default_setup

				default_write (uses default_setup)
				default_read  (uses default_setup)
				core_setup    (uses default_setup)
				core_write    (uses default_write)
				core_read     (uses default_read)

				Access adapter in php:
				Mage::getSingleton('core/resource')->getConnection('default_read')
			-->
			<default_write>
				<connection>
					<!--
						other handles can be referenced using "use"

						@see Mage_Core_Model_Config->getResourceConnectionConfig($name)
						If "use" is specified the connection data from the specified resource is
						loaded recursively
					-->
					<use>default_setup</use>
				</connection>
			</default_write>

			<core_setup>
				<!-- TODO: what's "setup" -->
				<setup>
					<module>Mage_Core</module>
				</setup>
				<connection>
					<use>default_setup</use>
				</connection>
			</core_setup>

			<!--
				TODO: what's the difference between the default_* and the core_* handles? Where are they used?
			-->


			<foobar_setup>
			<!--
				"foobar_setup" has to be a unique key that can be chosen freely.
				A folder with the same name needs to be in place in
				app/code/community/Foo/Bar/sql/foobar_setup and/or
				app/code/community/Foo/Bar/data/foobar_setup

				TODO: Describe the files that are located in those folders
				(install-...php, mysql4-upgrade-...-...php,...)
			-->
				<setup>
					<module>Foo_Bar</module>
					<class>Mage_Catalog_Model_Resource_Setup</class>
					<!--
						"class" default to Mage_Core_Model_Resource_Setup and can be overridden here

						Mage_Core_Model_Resource_Setup is the base class for flat models.
						Use Mage_Eav_Model_Entity_Setup (extends Mage_Core_Model_Resource_Setup) for EAV

						@see Mage_Core_Model_Resource_Setup->applyAllUpdates() (called in Mage_Core_Model_App::_initModules())
						@see Mage_Core_Model_Resource_Setup->applyDataUpdates() (called in Mage_Core_Model_App::run())
					-->
				</setup>
			</foobar_setup>
		</resources>

		<cache>
			<request_processors>
				<!--
					Request processors are asked before the actual request is executed by Magento.
					Magento EE's full page cache makes use of this mechanism (using the request processor class "Enterprise_PageCache_Model_Processor")

					Request processors set in Mage_Core_Model_Cache::__construct() and evaluated in Mage_Core_Model_Cache::processRequest()

					The string defined here needs to be a plain php class name class ids are not allowed here

					The processor must implement following method:
					$content = $processor->extractContent($content)
				-->
				<foobar>Foo_Bar_Model_Processor</foobar>
			</request_processors>

			<!--
				TODO: define other cache settings here
			-->
		</cache>

		<full_page_cache>
			<!--
				Magento EE's full page cache configuration goes here
			-->
		</full_page_cache>

		<!--
			Simple Url rewrites

			@see http://www.excellencemagentoblog.com/simple-url-rewrite-using-magento-xml
			@see Mage_Core_Controller_Varien_Front->rewrite()
		-->
		<rewrite>
			<fancy_url>
				<from><![CDATA[/manufacturer\/(.*)/]]></from>
				<to><![CDATA[manufacturer/index/index/manufacturer/$1/]]></to>
				<complete>1</complete>
			</fancy_url>
		</rewrite>

		<!--
			Register new product types here.

			Following basic products will be registered in Mage_Catalog
		-->
		<catalog>
			<product>
				<type>
					<simple translate="label" module="catalog">
						<label>Simple Product</label>
						<model>catalog/product_type_simple</model>
						<composite>0</composite>
						<index_priority>10</index_priority>
					</simple>
					<grouped translate="label" module="catalog">
						<!-- ... -->
					</grouped>
					<configurable translate="label" module="catalog">
						<!-- ... -->
					</configurable>
					<virtual translate="label" module="catalog">
						<!-- ... -->
					</virtual>
				</type>
			</product>
		</catalog>

	</global>

	<default>
		<!-- Contains definitions shared between all stores configuration -->

		<!--
			TODO: provide concrete examples
			- Directory structure, real folder names
			- System locale
			- Design and theme configuration
			- System options
		-->

		<!--
			Access this configuration using Mage_Core_Model_Config
			@see Varien_Simplexml_Element
		-->

		<web>
			<routers>
				<!--
					Registering a new router.

					Don't confuse this with registering a new route and using an existing route, that is
					done in config/frontend/routers.

					The "admin" and the "standard" routers are configured in Mage_Core. Then there is a hardcoded "default"
					router that handles 404s and Mage_Cms introduces a new routers using the event "controller_front_init_routers"

					@see Mage_Core_Controller_Varien_Front->init()
				-->
				<admin>
					<disabled>true</disabled><!-- Routers can be disabled like this -->
					<area>admin</area>
					<class>Mage_Core_Controller_Varien_Router_Admin</class>
				</admin>
				<standard>
					<area>frontend</area>
					<class>Mage_Core_Controller_Varien_Router_Standard</class>
				</standard>
			</routers>
		</web>

		<advanced>
			<modules_disable_output>
				<Foo_Bar>1</Foo_Bar>
				<!--
					Disable output from all block os Foo_Bar. This equals to disabling block output in the backend and
					can be overriden there. Also note, that this won't deactivate the module, but only prevent blocks
					from being rendered.
					To disable a module set config/modules/<moduleName>/active to false
				-->
			</modules_disable_output>
		</advanced>

	</default>

	<!-- TODO: How to add store specific configuration? -->

	<frontend>
		<!-- Contains definitions that are only required for the frontend -->

		<!--
			TODO: provide concrete examples
			- Routers
			- Translation files
			- Layout xml files
			- Observer declarations
		-->

		<events>
			<!--
				@see Mage_Core_Model_App::dispatchEvent()
			-->

			<customer_login><!-- Event key -->
				<observers>
					<foobar_login><!-- Key for the listener. Has to be unique. Use your module name as namespace -->
						<type>model</type>
						<!--
							Allowed values are
							- 'model' or 'object': Will create a new instance of the observer class
							- 'disabled': Won't execute toe configured listener.
							- 'singleton' or everything else: Will reuse a singleton instance of the observer. This is
								the default value if nothing has been specified
						-->
						<class>foobar/observer</class>
						<!--
							The model can be freely chosen. Usually all listener implementations can be found in an
							"Observer" class by convention.
						-->
						<method>loginListener</method>
						<!-- Specify the method that should be called on the previously specified object here	 -->
					</foobar_login>

				</observers>
			</customer_login>
		</events>

		<routers>
			<foobar>
				<use>standard</use>
				<!--
					This defines which front controllers to use. By default following front controllers exist
					- standard
					- admin
					- default
					- cms
					TODO: is that correct
				-->
				<args>
					<module>Foo_Bar</module>
					<!-- Maps to Foo/Bar/controllers/... -->
					<frontName>foobar</frontName>

					<!--
						Rewrites (usually done from another module to change or extend the original controller)
					-->
					<modules>
						<Bar_Foo before="Foo_Bar">Bar_Foo_Foobar</Bar_Foo>
						<!--
							Maps to Bar/Foo/controllers/Foobar
							The rest of the directory structure must match the original directory structure
						-->
						<!--
							"before" will lead to your class being asked before the configured on. There also is
							"after". Use those to control priorities. Having your class inheriting from the original
							class is a good idea anyways, so "before" will be good in most cases.
						 -->
					</modules>

				</args>
			</foobar>
		</routers>

		<layout>
			<updates>
				<foobar><!-- Can be freely chosen -->
					<file>foobar/foobar.xml</file>
					<!--
						It's a good best practice to group files coming from a module in a separate folder
					-->
				</foobar>
			</updates>
		</layout>


	</frontend>



	<admin><!-- TODO: where is admin used and where adminhtml? -->
		<!-- Contains definitions that are only required for the backend -->

		<!--
			Initialization of the backend router

			@see Mage/Adminhtml/etc/config.xml
		-->
		<routers>
			<adminhtml>
				<use>admin</use>
				<args>
					<module>Mage_Adminhtml</module>
					<frontName>admin</frontName>
					<!--
						This can be overridden (e.g. in local.xml) to choose a different url for the backend
					-->
				</args>
			</adminhtml>
		</routers>
	</admin>

	<!--
		Deprecated!

		Configure this in a separate files adminhtml.xml
	-->
	<adminhtml>
		<menu></menu>
		<acl></acl>
	</adminhtml>



	<catalog>
		<!-- Contains definitions for Mage_Catalog -->
	</catalog>



	<crontab>
		<jobs>
			<foobar_examplejob><!-- Choose a crontab key. Prefix with your module name to avoid naming conflicts -->
				<schedule>
					<cron_expr>0 1 * * *</cron_expr>
					<!-- Concrete cron syntax -->

					<!-- or:  -->
					<config_path>system/foobar/examplejob_cronexpr</config_path>
					<!--
						Do not hardcode cron expressions, but make them configurable using the config_path
						node instead. You can still provide a default value.
					-->

				</schedule>
				<run>
					<model>foobar/cron::exampleJob</model>
					<!--
						Here you specificy the class AND the method separated by '::'.
						This is different to how class and method is specified for event observers
					-->
				</run>
			</foobar_examplejob>
		</jobs>
	</crontab>


</config>

<!--
	TODO: see Mage/Page/etc/config.xml for  more configuration parameters (layouts,...)
-->