Года 4 назад познакомился с очень интересным и развивающимся проектом - Warden.Dev
Это оркестратор локальной среды разработки. По факту, все что описано в статье с оркестратором сводится к 3 командам: 1. `warden env-init` 2. `warden sign-certificate` - выполняется один раз при первоначальной настройке 3. warden env up
Так вопрос импорта все равно остается открытым. Есть сотня xls файлов разной структуры. И это все вручную заносится контент-менеджерами в вашу систему?
Использую данное устройство для TimeMachine. Вещь отличная.
Была только одна проблем. Стоял transmittion, все прекрасно работало до очередного обновления ПО.
После обновления transmittion перестал работать, хотя в системе остался. Попытка переустановить привела к окирпичиванию устройства.
Пришлось разбирать и доставать хард, чтобы восстановить
Бывает конечно и хардкод, но в основном (то что я встречал) именование блоков остается неизменным. Поэтому к ним не составит труда обратиться через layout.
Буду ждать новые статьи. Всегда интересно пообщаться с единомышленниками
Коль речь зашла о правильности использования ивентов вместо рерайтов, то логичнее добавить колонку в грид через ивенты.
Для этого достаточно добавить observer на core_block_abstract_prepare_layout_after или core_block_abstract_prepare_layout_before и в методе обсервера проверять тип блока.
if ($_block->getType() == 'adminhtml/sales_order_grid') {}
Есть второй способ — это добавление колонок через layout
Для этого достаточно добавить в файл layout:
filter_index используется при поиске если поле фильтруемо. Здесь необходимо указать значение. которое будет подставляться в sql запрос. Например, main_table. is_exported
renderer — Указываем блок, который будет отвечать за рендеринг. Данные поля являются необязятельными.
Я вам говорю про то что мы имеем с коробки. А с коробки мы имеем валидатор, который оперирует css селекторами элементов.
Про то что делают другие разработчики я не говорю, и глубоко уверено, что если разработчики пытаются изобретать велосипеды не посмотрев, что уже есть и чем можно воспользоваться — это плохой разработчик стиль кодирования. А код смотреть нужно для того, чтобы сказать так ли необходимо было изобретать новые валидаторы или достаточно было воспользоваться стандартным прототайповским.
Пошаговая инструкция это очень здорово для начинающих разработчиков. Но я уверено, что любой более или менее продвинутый разработчик, который уважает свое время пользуется либо генераторами шаблона модуля либо еще какими-либо плюшками. Например есть оличный плагин для PhpStorm (Magicento) который позволяет создавать вполне работоспособную заготовку.
Данный вариант использования RDBMS был введен начиная с Magento CE 1.6 / EE 1.11
Начиная с этих версий конечно же предпочтительно использовать подобный стиль.
Но в предыдущих версиях приходилось пользоваться run.
Кстати начиная с 1.6/1.11 так рекомендовано ресурсные модели перенести из папки Mysql4 в директорию Resource
Я не говорю, что ваше решение хуже или повторяет представленное решение. Моя была о том, что оба решения опираются на использование стандартной валидации и уже из этого начинаются все остальные пляски.
Мне жаль, что вам не понятны эти куски кода…
На счет local.xml вы правы, это я не доглядел в статье. Он грузится из папки app/etс дважды, дабы магазин работал всегда. Обусловлено это тем, что все грузиться в единую древовидную структуру.
Увидим ли мы ваши статьи с «красивыми сиквенс диаграммами» и прочими красотулями?
reinit тоже расписывать не буду когда и как вызывается.
В заключении можно сказать, что указанный вами метод init вызывается только при вызове Mage::app() или Mage::init с пустым массивом $modules
Эти методы обычно используются при написании сторонних php скриптов, запускающихся из терминала, либо кроном.
Я же в статье рассматрива метод run из index.php (т.е. стандартного метода запуска магазина), который запускает всю цепочку.
Года 4 назад познакомился с очень интересным и развивающимся проектом - Warden.Dev
Это оркестратор локальной среды разработки. По факту, все что описано в статье с оркестратором сводится к 3 командам:
1. `warden env-init`
2. `warden sign-certificate` - выполняется один раз при первоначальной настройке
3. warden env up
Думаю такое решение вполне может подойти и для российских магазинов
Была только одна проблем. Стоял transmittion, все прекрасно работало до очередного обновления ПО.
После обновления transmittion перестал работать, хотя в системе остался. Попытка переустановить привела к окирпичиванию устройства.
Пришлось разбирать и доставать хард, чтобы восстановить
Буду ждать новые статьи. Всегда интересно пообщаться с единомышленниками
Для этого достаточно добавить observer на core_block_abstract_prepare_layout_after или core_block_abstract_prepare_layout_before и в методе обсервера проверять тип блока.
Есть второй способ — это добавление колонок через layout
Для этого достаточно добавить в файл layout:
filter_index используется при поиске если поле фильтруемо. Здесь необходимо указать значение. которое будет подставляться в sql запрос. Например, main_table. is_exported
renderer — Указываем блок, который будет отвечать за рендеринг. Данные поля являются необязятельными.
Про то что делают другие разработчики я не говорю, и глубоко уверено, что если разработчики пытаются изобретать велосипеды не посмотрев, что уже есть и чем можно воспользоваться — это плохой
разработчикстиль кодирования. А код смотреть нужно для того, чтобы сказать так ли необходимо было изобретать новые валидаторы или достаточно было воспользоваться стандартным прототайповским.Начиная с этих версий конечно же предпочтительно использовать подобный стиль.
Но в предыдущих версиях приходилось пользоваться run.
Кстати начиная с 1.6/1.11 так рекомендовано ресурсные модели перенести из папки Mysql4 в директорию Resource
Наверняка почерпнуто из inchoo.net/ecommerce/magento/track-validation-errors-on-magento-forms-using-google-analytics/
На счет local.xml вы правы, это я не доглядел в статье. Он грузится из папки app/etс дважды, дабы магазин работал всегда. Обусловлено это тем, что все грузиться в единую древовидную структуру.
Увидим ли мы ваши статьи с «красивыми сиквенс диаграммами» и прочими красотулями?
Я расписал процессы, Вы указали пункты… Смыслы то не поменялся.
Если внимательно пройтись по коду, а еще лучше дебагером, то можно заметить что метод init вызывается только в 3 случаях:
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/cron.php#L67
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L270
github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/Config.php#L370
Первый случай вообще рассматривать не будет, т.к. это процесс запуска по крону. (Причем для cron.php init запустится дважды)
Для второго случая метод github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/code/core/Mage/Core/Model/App.php#L258 вызывается в двух случаях:
1) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L615 — вызывается только если свойсто app не определено (в случае cron.php это будет первый запуск)
2) github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L640
В случае запуска страницы в браузере 1 сразу исключается т.к. github.com/LokeyCoding/magento-mirror/blob/magento-1.8/app/Mage.php#L669 свойсто не будет равно null
2 будет отрабатывать только если массив $modules будет пустым
reinit тоже расписывать не буду когда и как вызывается.
В заключении можно сказать, что указанный вами метод init вызывается только при вызове Mage::app() или Mage::init с пустым массивом $modules
Эти методы обычно используются при написании сторонних php скриптов, запускающихся из терминала, либо кроном.
Я же в статье рассматрива метод run из index.php (т.е. стандартного метода запуска магазина), который запускает всю цепочку.