Magento для PHP MVC разработчиков (Alan Storm) – ч.1/11

 

 

 

Часть 1. Настройка Magento. Создание модуля

 

Конфигурирование является сердцем Magento-системы. Поэтому, в этом описании почти все внимание будет сосредоточено на конфигурации модуля (module/etc). Это уровень абстракции, с которым большинство PHP-разработчиков не работает. И хотя такая логика увеличивает время разработки из-за беспорядка и запутанности в начале, она также предоставляет беспрецедентную гибкость и возможность переписывать базовые функции системы своими собственными (не вмешиваясь при этом в само ядро).

Начнем с того, что мы создадим модуль Magento, который позволит просматривать всю конфигурацию системы в окне веб-браузера. На начальной стадии от вас требуется только уметь копировать и вставлять куски кода. Чуть позже вы уже и сами будете знать без объяснений, что тот или иной код делает.

 

 

Настройка структуры каталогов модуля

Стоит отметить, что большая часть базовой системы Magento построена с использованием модульной системы. Если вы посмотрите в app/code/core/Mage, то увидите, что каждая папка представляет собой отдельный модуль, каждый из которых разрабатывался разными командами программистов компании. Все вместе эти модули образуют общую систему движка (ядро).

Ваши собственные модули должны размещаться в этом каталоге: app/code/local/Packagename.

«Packagename» (название пакета модулей) должен быть уникальным в комбинации Namespace/Package (пространство имен/пакет). Это неофициальное правило, и оно заключается в том, что название пакета модулей должно включать название компании (или свои инициалы). Идея заключается в том, чтобы название модулей было уникальным и не совпадало с уже имеющимися во всем мире.

Когда я работаю над своими проектами с Magento, я использую версию своего доменного имени (Alanstormdotcom). Вы же должны использовать собственное пространство имен.

 

Таким образом, чтобы добавить новый модуль в свою Magento-систему, создайте следующую структуру каталогов. Обратите внимание, что используется локальная среда разработки (local), то есть мы не меняем код ядра (core). Alanstormdotcom – это  название пакета модулей (используйте собственное), а Configviewer – это название модуля.

 

app/code/local/Alanstormdotcom/Configviewer/Block
app/code/local/Alanstormdotcom/Configviewer/controllers
app/code/local/Alanstormdotcom/Configviewer/etc
app/code/local/Alanstormdotcom/Configviewer/Helper
app/code/local/Alanstormdotcom/Configviewer/Model
app/code/local/Alanstormdotcom/Configviewer/sql

 

Вам могут и не понадобиться все эти папки в каждом модуле, но их развертывание – это довольно хорошая идея.

Далее, нужно создать два файла. Во-первых, это config.xml. Его сохраняем в папке

 

app/code/local/Alanstormdotcom/Configviewer/etc/config.xml

 

Второй файл (Alanstormdotcom_Configviewer.xml) должен быть создан по адресу

 

app/etc/modules/Alanstormdotcom_Configviewer.xml

 

Оговорено, что именоваться эти файлы должны в виде Packagename_Modulename.xml (Название пакета модулей_Название модуля). Они отвечают за включение/отключение модулей в системе.

Файл config.xml должен содержать следующую XML структуру (не беспокойтесь слишком сильно о том, что делает весь этот код, о нем мы узнаем в ближайшее время).

 

<config>
  <modules>
    <Alanstormdotcom_Configviewer>
       <version>0.1.0</version>
    </Alanstormdotcom_Configviewer>
  </modules>
</config>

 

А файл Alanstormdotcom_Configviewer.xml должен содержать следующую XML структуру.

<config>
  <modules>
    <Alanstormdotcom_Configviewer>
      <active>true</active>
      <codePool>local</codePool>
    </Alanstormdotcom_Configviewer>
  </modules>
</config>

 

Вот и все, теперь у вас есть голый костяк модуля, который не будет делать ничего, но Magento его уже будет видеть. Чтобы убедиться в правильности своих действий:

• Очистите кэш Magento
• В меню администратора Magento перейдите в Система -> Конфигурация -> Расширенная (System -> Configuration -> Advanced)
• Разверните вкладку «Отключить вывод модулей» (Disable modules output), если она свернута
• Убедитесь, что Alanstormdotcom_Configviewer появился в списке

 

Поздравляем, вы создали свой первый модуль Magento!

 

 

Создание файла настроек модуля (config)

Конечно, этот модуль еще ничего не делает. Но когда мы его закончим, — он будет:

• Проверять наличие переменной «showConfig» в строке запроса в браузере
• Если запрос «showConfig» есть в наличии, тогда будет показывать всю конфигурацию движка Magento
• Проверять в запросе наличие дополнительной переменной, showConfigFormat, что позволит нам определять, в каком формате выводить результат – текстовом или XML.

 

Во-первых, к нашему config.xml файлу добавим раздел <global>:

 

<config>
  <modules>...</modules>
  <global>
    <events>
      <controller_front_init_routers>
       <observers>
        <alanstormdotcom_configviewer_model_observer>
          <type>singleton</type>
          <class>Alanstormdotcom_Configviewer_Model_Observer</class>
          <method>checkForConfigRequest</method>
       </alanstormdotcom_configviewer_model_observer>
      </observers>
     </controller_front_init_routers>
    </events>
  </global>
</config>

 

Затем создаем файл ../Alanstormdotcom/Configviewer/Model/Observer.php и размещаем в нем следующий код:

 

<?php

class Alanstormdotcom_Configviewer_Model_Observer {

const FLAG_SHOW_CONFIG = 'showConfig';
const FLAG_SHOW_CONFIG_FORMAT = 'showConfigFormat';

 
private $request;
 
public function checkForConfigRequest($observer) {
    $this->request = $observer->getEvent()->getData('front')->getRequest();
    if($this->request->{self::FLAG_SHOW_CONFIG} === 'true'){
       $this->setHeader();
       $this->outputConfig();
    }
}
 
private function setHeader() {
    $format = isset($this->request->{self::FLAG_SHOW_CONFIG_FORMAT}) ?
    $this->request->{self::FLAG_SHOW_CONFIG_FORMAT} : 'xml';
    switch($format){
      case 'text':
        header("Content-Type: text/plain");
        break;
      default:
        header("Content-Type: text/xml");
    }
}
 
private function outputConfig() {
    die(Mage::app()->getConfig()->getNode()->asXML());
}


}

Вот и все. Очистите кэш Magento, а затем загрузите любой URL своего сайта на Magento с добавленной в конце строкой ?showConfig=true

    vash-domen/?showConfig=true

 

 

На что обратить внимание?

Перейдя по этой ссылке вы увидите гигантской XML файл. Это полное описание состояния текущей Magento-системы. В нем перечислены все модули, модели, классы, обработчики событий и почти все, что может потребоваться при разработке.

Например, рассмотрим созданный выше файл config.xml. Если вы воспользуетесь поиском в браузере (Ctrl+F) и проверите наличие строки Configviewer_Model_Observer, то вы найдете этот класс в описании системы. Каждый файл config.xml модуля обрабатывается Magento и включается в глобальную конфигурацию (global config).

 

 

Какая мне от этого польза?

Сейчас это может показаться странным, но эта конфигурация является ключом к пониманию движка Magento. Каждый модуль, который вы будете создавать, будет добавлен к этой конфигурации, а доступ ко всем настройкам системы очень часто может быть полезным разработчикам.

Рассмотрим небольшой пример, перед тем как перейдем к более практическим вещам. Как MVC-разработчик вы, вероятно, использовали определенные хелперы, создавая экземпляр класса вроде

 

    
    $helper_sales = new HelperSales();

 

Magento абстрагировался от использования декларативных классов PHP. В Magento, упомянутый выше код, выглядит примерно так:

 

    
    $helper_sales = Mage::helper('sales/data');

 

Простым языком, этот статический метод будет:

• Осматривать секцию <helpers/> в настройках (Config)
• В секции <helpers/> осматривать секцию <sales/>.
• В секции <sales/> осматривать секцию <class/>.
• Использовать базовое имя класса, найденное в пункте №3 (Mage_Sales_Helper), для построения полного имени класса Mage_Sales_Helper_Data

 

Ключевым преимуществом созданного модуля является возможность посмотреть в файле конфигураций имя классов. Зная это, мы можем с помощью собственного модуля переопределить базовую функциональность Magento без изменения или добавления к ядру системы дополнительного кода. Такой уровень мета-программирования, как правило, не встречается в PHP, но он позволяет аккуратно расширить только те части системы, которые нужно.

 

 

 

Автор: Alan Storm (http://alanstorm.com/magento_config/)

Перевод на русский: SebWeo