Pull to refresh

Comments 27

Создавать таблицу через run как бы моветон.
Более предпочтительный подход — через newTable, как-то так:

$installer->startSetup();
$connection = $installer->getConnection();
$table = $connection
    ->newTable($installer->getTable('dsnews/table_news'))
    ->addColumn( ... и т.д.


т.е.вы сначала описываете таблицу в конфиге, а потом уже ее создаете!
Спасибо, учту. Но в настоящем руководстве намного удобнее использовать SQL код — имхо, он более понятен и прост. Ну, а проблемы совместимости с другими базами данных можно решать тогда, когда будет поддержка других баз данных, помимо MySQL :)
А зачем вообще создавать себе проблемы, чтобы потом их решать?
Когда добавят поддержку других БД, то код работающий на уровне абстракции connection думаю без проблем будет работать и с другими БД, ну или его придется совсем немного изменить.
Обновил статью, а также код примеров. Это была довольно трудоёмкая задача. И, хотя я считаю SQL код понятнее и приятнее, я согласен с тем, что нужно стараться с самого начала писать код правильно.
На самом деле поддержка есть уже как минимум mssql и oracle. Но она не доступна для community редакции.
Данный вариант использования RDBMS был введен начиная с Magento CE 1.6 / EE 1.11
Начиная с этих версий конечно же предпочтительно использовать подобный стиль.
Но в предыдущих версиях приходилось пользоваться run.
Кстати начиная с 1.6/1.11 так рекомендовано ресурсные модели перенести из папки Mysql4 в директорию Resource
А разве писать код html внутри php файлов ядра айс?

foreach ($news as $item) echo '<h2><a href="' . $viewUrl . '?id=' . $item->getId() . '">' . $item->getTitle() . '</a></h2>';

Я не разбираюсь в Magento, но очень похож на мой велосипед по структуре модулей, но там же есть хелперы html тегов. Не поверю, что в Magento их нет. Типа:

foreach ($news as $item) echo HTML::h2(HTML::a($viewUrl . '?id=' . $item->getId(),$item->getTitle());

Ну а так спасибо, познавательно для сравнения почитать.
А разве писать код html внутри php файлов ядра айс?

Не ядра, а шаблонов. Разработчики Magento не стали заморачиваться использованием классов шаблонизаторов и в качестве шаблонизатора используют сам PHP. Все шаблоны находятся в директории /app/design/[frontend/backend]/[package]/[theme]/template/.

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

<img src="<?php echo $this->escapeHtml($news->getImageUrl()); ?>">

где $this — это экземпляр блока, наследуемый от класса Mage_Core_Block_Abstract. Если нужно/удобнее, то можно в собственном блоке определить дополнительные методы создания элементов, однако в основном в этом нет необходимости.
Ясно. Меня смутило, что выше есть строчка «Изменить контроллер controllers/IndexController.php». (Шаг 7, Пункт 5). А как по вашему опыту в шаблонах много мешанины html<->php, можно примерчик из сборки? А то одни ругают, когда в шаблоне много кода, а в мадженте как… или она изначально подразумевает, что ею занимаются подготовленные специалисты и не пускает чайников-самоучек?
Промахнулся с кнопкой «Ответить». Ответ ниже другим комментарием :)
В данном случае я просто показал пример того, что возможно сделать так. В следующем шаге показывается как нужно правильно использовать шаблоны с помощью механизмов блоков.

А то одни ругают, когда в шаблоне много кода, а в мадженте как…

В Magento много шаблонов :)

можно примерчик из сборки?

можно взглянуть на шаблоны в директории базовой темы самой Magento: /app/design/frontend/base/default/template — там этих шаблонов много, и любой из этих шаблонов можно заменить в собственной теме (убрать лишний функционал, либо добавить что-то новое).
А заказчику как сдается проект с персональным шаблоном, одна папка с шаблоном или папок много и их нужно в ручном режиме грузить в разные директории по карте. А какое количество файлов-шаблонов всего у одного дизайна (менее 100, 100-300, больше 300, тьма) и сколько по опыту в среднем шаблонов приходится править для нарезки персонального дизайна заказчика (ну не все же они правятся, обычно несколько основных, аля главный вид товаров, общий вид, новости и т.д.)?
Заказчику обычно предоставляется готовый сайт :) Вообще в базовой теме более 500 файлов шаблонов. Количество шаблонов, которые нужно исправлять/добавлять обычно колеблется от 50 до 150 в зависимости от дизайна. Чем ближе дизайн к основной теме, тем меньше шаблонов нужно править (можно изменить внешний вид с помощью стилей). В одном из больших проектов, в разработке которого я принимал участие, около 250 файлов шаблонов.

Все шаблоны хранятся в директории текущей темы, т.е. для каждого проекта создаётся своя собственная тема. Там же хранятся макеты темы. Однако готовые темы обычно предоставляются в виде архивов, которые нужно распаковать в корневую директорию сайта из-за большого разброса директорий, в которых могут находиться нужные файлы: app/code/, app/design/frontend/, js/, skin/frontend и т.д…

Отвечая на предыдущий вопрос: порог вхождения в Magento действительно выше, чем для большинства других систем. Это и из-за сложности системы, и из-за недостатка хорошей документации и сложности понимания механизмов. В большинстве случаев приходится копаться в исходных классах для того, чтобы понять как работает тот или иной механизм. Это одна из тех причин, почему я и написал данную статью, попытавшить выделить основные моменты и объяснить их. В среднем для человека, который хорошо знаком с PHP, требуется около 2-3 месяцев обучения и практики для того, чтобы начать нормально работать в Magento.
Если заказчик решит обновить ПО, есть ли защита от стирания персонально настроенных файлов, разбросанных по папкам разным? У модулей есть система обновления? Можно ли делать триальные модули и модули с серийным номером для дистрибуции?
В том и смысл создания отдельной темы, чтобы при обновлении системы файлы не были перезаписаны, т.к. все файлы базовой темы, а также ядро системы будут обновлены. А вообще обновление системы лучше производить в среде разработки (в песочнице) и после очень тщательно тестировать, т.к. существует немаленькая вероятность того, что после обновления что-то сломается.

Можно ли делать триальные модули и модули с серийным номером для дистрибуции?

Можно, как и в любых других системах.
Пошаговая инструкция это очень здорово для начинающих разработчиков. Но я уверено, что любой более или менее продвинутый разработчик, который уважает свое время пользуется либо генераторами шаблона модуля либо еще какими-либо плюшками. Например есть оличный плагин для PhpStorm (Magicento) который позволяет создавать вполне работоспособную заготовку.
Данная инструкция не только для того, чтобы показать как делать, но и для того, чтобы показать как формируются используемые значения — откуда берутся, зачем нужно прописывать те или иные значения, где они хранятся и как их изменять. Здесь я постарался осветить не совсем очевидные нюансы формирования значений.

Например: думаю, что для большинства Magento разработчиков тег layout-a <custom_index_index> будет означать роутер custom, контроллер IndexController и действие indexAction. И в большинстве случаев так и есть, т.к. разработчики предпочитают писать название тега frontend и frontName одинаковыми, хотя на самом деле custom — это имя тега в секции frontend, которое может отличаться от frontName.

Ну и, конечно же, большая часть данного руководства посвящена возможностям админки — формы, гриды и т.д… используя встроенные возможности Magento.
Понимаю, что статья предназначена для знакомства с самим процессом создания модуля, но всё же…
В разделе «Шаг 15. Добавление поля загрузки изображения» в пункте 3 в методе getImageUrl вместо строки:
return $helper->getImageUrl();

наверное надо так:
return $helper->getImageUrl($this->getId());

иначе метод нерабочий.
Пардон, если не в тему.
Да, моя ошибка, исправил в статье. В исходных кодах для примера всё было правильно, а в тексте, видимо, забыл исправить.
Разбираюсь c созданием нового модуля. Версия Magento ver 1.9.2.1 — Added Aug 4 2015. При проверке пункта 5 выдаёт:
Array
(
[0] => default
[1] => STORE_default
[2] => THEME_frontend_rwd_default
[3] => dsnews_index_index
[4] => customer_logged_out
)

Как это исправить, и правильно подключить frontend и layout?.. Всё проверял на Ваших исходниках. Возможно версию Magento переустановить?
В моих примерах и описаниях в квадратных скобках приведены [изменяемые переменные], т.е в данном случае стоит package rwd и theme default, т.е. шаблоны нужно класть по пути /app/design/frontend/rwd/default, а скрипты и стили — /skin/frontend/rwd/default
Спасибо, теперь разобрался.
Название класса блока грида формируется из значений, заданных в пункте 1 в блоке DS_News_Block_Adminhtml_News: [_blockGroup]/[_controller]_grid, где _blockGroup — это название узла блоков модуля config/global/blocks/[_blockGroup]. В результате получится строка типа блока «dsnews/adminhtml_news_grid».


А если у меня блоки в config.xml указаны так:

<blocks>
            <dsnews>
                <class>My_Module_Block</class>
            </dsnews>
        </blocks>


То, получается, имя класса грида должно быть My_Module_Block_Adminhtml_News_Grid?

Как "«dsnews/adminhtml_news_grid" преобразовалось в DS_News_Block_Adminhtml_News_Grid?
        $this->_blockGroup = 'dsnews';
        $this->_controller = 'adminhtml_news';


Из этих строчек получилось dsnews/adminhtml_news, после чего добавилось хардкорное значение _grid, в результате получилось dsnews/adminhtml_news_grid.

По названию dsnews определяется класс blocks/dsnews/class, в вашем случае My_Module_Block, а дальше просто добавляется то, что имеется в пути — adminhtml_news_grid преобразуется в _Adminhtml_News_Grid, которое добавляется к названию вашего класса. Итого имеем название класса My_Module_Block_Adminhtml_News_Grid
Спасибо вам за ответ.
Назвал класс таким образом, но судя по всему, он вообще не отрабытывает, хотя My_Module_Block_Adminhtml_News — OK. Вызов хелпера Mage::helper('dsnews'); возврщает такое вот:

object(My_Module_Helper_Data)[798]
  protected '_moduleName' => null
  protected '_request' => null
  protected '_layout' => null

Так же быть не должно?
если создать блок с гридом так
$contentBlock = $this->getLayout()->createBlock('dsnews/adminhtml_news_grid');

то он отрабатывает. Но то ли я не понял фишку, то ли вы в этой части не упомянули о том, что надо класс инстанцировать прямо.
Я не вижу ваш код, поэтому сложно сказать, что именно происходит не так. Но могу предположить, что проблема в наследовании. Чтобы грид в админке заработал, основной блок должен наследоваться от класса Mage_Adminhtml_Block_Widget_Grid_Container, тогда грид будет вызываться автоматически.
Only those users with full accounts are able to leave comments. Log in, please.