hook pre render Идея и примерная реализация

[sv2109]

sv2109, посмотрел твой вариант (извиняюсь, что бегло). Это получается, что надо регистрировать много событий в том же system/engine/controller.php? Правильно? Не фен-шуйно... Вот если сделать API для регистрации событий, то это будет другое дело.

Вы говорите о Event Dispatcher? Так это и есть апи для регистрации событий. В одном файле добавляется событие с помощью одной строчки кода. В другом файле (своем модуле) пишется обработчик этого события. Все делается согласно паттерну Наблюдатель, куда уже феншуйнее :)) Плюс именно этот подход используется и в Друпале и в Симфони, системы, которые пишутся целыми командами профессионалов и раз они пришли с годами именно к такой реализации значит она не может быть неправильной.

Событий не будет много. Например один пререндер в контроллере покроет процентов наверное 80% всего, что сейчас делается через vqmod, потому что только с помощью него можно будет переопределить ВСЕ переменные шаблона и добавить свои. Плюс добавить еще штук 5-10 в ключевых точках кода (тут нужно подумать где именно).

[Petr]

В друпаел очень много багов которые разработчики просто игнорируют, около месяца назад читал статью на Хабре, то что последняя стабильная версия это 5 или 6, точно уже не помню, после этого галимые сборки пошли с кучей багов. Там даже подсчет был что ст такой кучей багов друпалу просто не вывезти, либо разработчиков нанимать сотнями либо работать 24 часа . Может из за этого Даниель обеими рогами в земле.

[Petr]

Vqмод очень кривое средство, но для обычных юзеров это панацея. Я просто до того как на opencart перейти пользовался Virtuemart и osCommerce. Я не программирую и не пишу модули, поэтому рассматриваю все со стороны удобства. Большинство модулей которые мне нужны обычно добавляли всякие строчки кода типа названия пунктов и и т.д. Гораздо реже встречаются replace.

Мне как юзеру очень не удобно например такая ситуация, что у меня есть один модуль который не видит другой. Например обычный менеджер не видит дополнительные столбцы которые появились в БД, данные из которых так хотелось что бы отображались и работали со всем функционалом. Во общем проблема в том что все модули стараются написать под стандарт определенный, а хочется гибкости но не на уровне программирования и ковыряние в коде, а визуальности интерфейса, что бы можно было например из БД самому выбирать какие колонки у товара отображать, и весь этот интерфейс управления еще бы на ajaxe написать.

[cmd]

sv2109, значит я не до конца понял принцип работы. Сегодня попробую и отпишу вечером.

Petr, про Drupal бред. На 7.х наберется дюжины две подтвержденных багов и все они исправно устраняются разработчиками. В OC багов не меньше.

[Petr]

блин все таки я нашел эту тему http://habrahabr.ru/post/128208/

[Petr]

Август 2011: 4153 незакрытых багов (22 181 всего — почти вдвое больше, чем два года назад), апгрейд по-прежнему затруднён для многих пользователей, застрявших на Drupal 6, близкий к нулю прогресс в разработке Drupal 8.

Мне кажется у opencart меньше? :-)

[sv2109]

блин все таки я нашел эту тему http://habrahabr.ru/post/128208/

Мне кажется у opencart меньше? :-)

Скажите, пожалуйста, сколько сайтов вы сделали на Друпале, сколько модулей для него написали, с какими апи работали итд? Зачем говорить о том в чем не разбираетесь?

Почитайте например вот этот комментарий на хабре о системе баг трекинга на друпал.орг и все станет на свои места.

Еще есть статья одного уважаемого друпалера обо всем этом "друпал кризисе"..

И вообще прекращаем флуд в теме.

[sv2109]

...а хочется гибкости но не на уровне программирования и ковыряние в коде, а визуальности интерфейса...

Ага, а еще лучше одну большую кнопку "Сделать хорошо" :)

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

[Petr]

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

Ну тут смысл спорить, есть такая пословица "Если хочешь что то сделать хорошо сделай это сам.." - просто open source проекты рассчитаны на гибкость в решении задач, некоторые модули сделаны просто отлично, иногда даже спрашиваешь себя, зачем в новой версии оставлять старое, ведь столько хорошего понаписано, которое просто не может не понравится ну или вызвать отрицательные эмоции при пользовании. Я подвожу к мысли что сама эволюция движка, мне кажется должна в новые сборки включать самое лучшее, а не оставлять все по старому, тогда и не нужно будет множество модулей покупать которые используют vqmod. А если я бы заказывал сайт то ТЗ которое мне бы понадобилось вытянуло бы в в сумму гораздо большую, чем купить это в виде модулей у сторонних разработчиков. При этом покупая модуль он сделан максимально конкурентоспособным, а заказывая функционал иногда детали которые у тебя сидят в голове и кажутся очевидными, до разработчика просто не доходят :-) ну это и понятно. После покупки разумеется хочется привнести в модуль что то, что сделало бы его еще лучше, так даже с одной стороны помогаешь разработчику улучшить продукт, результат прямой лучше продукт = больше продаж. Для доработки купленного модуля разумеется нужен программист если в штате нет, соответственно человеку нужно разобраться в коде потратить время, в итоге выходит гораздо дороже самого модуля.

[Petr]

Почитайте например вот этот комментарий на хабре о системе баг трекинга на друпал.орг и все станет на свои места.

Да я согласен что автор топика приводит гораздо меньше ошибок для конкретной версии, но это все равно не является объективной оценкой самого качества движка, т.к. в основном рапортуют люди, о багах не факт что пред идущее баги были закрыты обновленной версией. Если объектно оценивать, то должен быт change log который закрывал бы все баги предидущих версий, я такого не нашел.

[cmd]

Установил чистую 1.5.4.1. Устанавливаю хак.... Открываю контроллер модуля featured.php для эксперимента (благо он прямо на главную выводится). Добавляю код, который должен переопределить название кнопки "My Account"

public function listeners() {
		return array(
		  'controller.pre_render' => 'preRender'
		);
}
public function preRender(Event $event) {
		$controller = $event->getSubject();
	  
		if (isset($controller->data['text_checkout'])) {
			  $controller->data['text_checkout'] = 'TEST';
		}	  
}

Не работает.

Пробую переопределить ссылку на главную

public function listeners() {
		return array(
		  'controller.pre_render' => 'preRender'
		);
}
public function preRender(Event $event) {
		$controller = $event->getSubject();
	  
		if (isset($controller->data['home'])) {
			  $controller->data['home'] = 'TEST';
		}	  
}

Работает.

Причину не знаю. Потом отпишу.

В целом все хорошо, но надо доработать, чтобы это было полноценным решением. Сейчас статичные шаблоны ограничевают возможности... и что-то ещё не так... sv2109, well done!

P.S. Предлагаю холливар о качестве Drupal закончить хотя бы потому что он скучный.

[sv2109]

Проверил, у меня

$controller->data['text_checkout'] = 'TEST';

Нормально заработало.. правда у меня версия 1.5.3.1, но мало вероятно что из-за этого.

Вот скрин http://www.diigo.com/item/image/39n05/5og8?size=o

Да, понятно, что это еще не полноценное решение. Нужно все проверить, протестировать. Нужно добавить несколько событий с которыми можно работать. Нужно сделать с десяток полезных примеров, чтобы показать другим как все работает и что это действительно полезно и удобно.

Кстати, насчет сборки.. Можно просто пойти по пути vqmod-а.. его же не включали в ядро и сборок отдельных не делали.. просто выложили где-то и показали всем как пользоваться.. Что можно сделать:

1. Допилить все, сделать нормальную документацию с примерами и запаковать все в отдельный модуль.

2. В модуле прописать несколько способов установки:

- через ручную правку файлов

- через копирование и перезапись уже измененных файлов (в этом случае нужно создавать отдельный файлы для каждой версии опенкарта)

- через vqmod

3. Выложить отдельным модулем с описанием.

Если решение нормальное, значит его оценят и со временем начнут писать модули под него. Как сейчас - загружаешь модуль и видишь - для использования нужен vqmod. Так же будет там - для использования нужен Event Dispatcher (или может проще ED).

[sv2109]

  $this->data['text_checkout_option'] = $this->language->get('text_checkout_option');
  $this->data['text_checkout_account'] = $this->language->get('text_checkout_account');
  $this->data['text_checkout_payment_address'] = $this->language->get('text_checkout_payment_address');
  $this->data['text_checkout_shipping_address'] = $this->language->get('text_checkout_shipping_address');
  $this->data['text_checkout_shipping_method'] = $this->language->get('text_checkout_shipping_method');
  $this->data['text_checkout_payment_method'] = $this->language->get('text_checkout_payment_method');
  $this->data['text_checkout_confirm'] = $this->language->get('text_checkout_confirm');

Я делаю так:

В контроллере добавляю 1 строчку:

  $this->data['l'] = $this->language;

В шаблоне вместо:

  <?php echo $text_checkout_option; ?>

пишу

  <?php echo $l->get('text_checkout_option');  ?>

[sv2109]

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

Зачем изобретать свои велосипеды, если это до вас уже неоднократно сделали?! Есть десятки уже готовых решений, написанных профессиональными разработчиками и отлаженными на тысячах сайтов.. Причем все опенсорсное, бери и пользуйся :) Вот например по формам - компонент Validator от Symfony или форм хелпер от фреймворка CodeIgniter, форм валидатор от CodeIgniter (ссылки на русскую документацию немного устаревшей версии фреймворка) итд. наверное в каждом фреймворке есть свой готовый класс для подобной рутины.

[sv2109]

Да я знаю, что есть. Сам достаточно работал с Zend, но осталось прикрутить к OpenCart/

То тогда лучше использовать компоненты Симфони. По нескольким причинам. 1. Не знаю насчет ZF, очень давно его изучал и то была какая-то древняя версия, а в Симфони все компоненты сделаны независимо и их можно подключать к сторонним приложениям. 2. Мне кажется, что почти все подобные компоненты более-менее одинаковы по функционалу, да что-то лучше реализовано в одном, что-то в другом но в основном почти тоже самое. 3. Один компонент от Симфони я уже прикрутил и чтобы не создавать зоопарка то лучше и другие брать именно от Симфони

Еще в симфони есть компонент Лоадер, который позволяет автоматизировать процесс подключения классов с использованием неймспейсов. Для одного компонента я не стал его подключать, но если будут другие то есть смысл его настроить и все подключать через него.

[cmd]

sv2109, у Вас есть виденье того как бороться со статичными страницами шаблонов (и в фронтэнде и в админке)?

[sv2109]

sv2109, у Вас есть виденье того как бороться со статичными страницами шаблонов (и в фронтэнде и в админке)?

У меня 2 варианта:

1. Добавить больше динамики в шаблоны. Приведу пример. Как сейчас все реализовано, например как выводятся табы для товара (написал без условий для лучшего понимания):

  <div id="tabs" class="htabs">
		<a href="#tab-description"><?php echo $tab_description; ?></a>
	<a href="#tab-attribute"><?php echo $tab_attribute; ?></a>
	<a href="#tab-review"><?php echo $tab_review; ?></a>
	<a href="#tab-related"><?php echo $tab_related; ?> (<?php echo count($products); ?>)</a>
  </div>

То есть все жестко прописано в коде и даже местами поменять например описание с атрибутами без правки шаблона не получится не говоря уже о том чтобы что-то добавить.

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

Так же можно и меню выводить и разные списки и например поля для товаров итд. При таком подходе очень много чего можно будет переопределить на сервере с помощью например тех же хуков.

2. Opencart использует паттерн MVC для разделения логики на слои. У каждого слоя своя область применения. Так вот слой Представления в это самый близкий до пользователя слой он специально с создавался чтобы можно было без знания php и баз данных вносить изменения в код. Руками! Открыл нужный шаблон и добавил несколько строк html кода, это сейчас даже школьники делают на уроках информатики. А если человек занимается созданием сайтов то он просто обязан знать самые азы html-а и при необходимости добавить пару строк html кода в шаблон не должно составить для него вообще никакой трудности.

А истина скорее всего где-то посередине. И если найти компромисс между этими двумя вариантами то получится то что нужно. Например максимально добавить динамики в шаблоны чтобы можно было программно их изменять. А то что нельзя так сделать (или не выгодно потому что сильно усложнит логику или скажется на производительности) - просто править руками. Тем кто не умеет - учить html :)

[sv2109]

vQmod - говно! Я когда увидел в коде опенкарта что его встраивают - заплевал весь монитор ...

... но кому такая сборка нужна? На форуме людей понимающих о чем идёт речь в этой теме - полтора человека... остальных всё устраивает..

Нам нужна! Чтобы при следующем открытии редактора не хотелось плевать в монитор, понимая с чем приходится работать! И чтобы работа не превращалась в скучную рутину для зарабатывания денег, а чтобы получать от этой работы элементарное удовольствие, понимая что работаешь с реально хорошим движком, что у этого движка есть реальные перспективы, что он не просто не хуже аналогов, а даже превосходит их по множеству параметров и при этом постоянно развивается в правильном направлении становясь от этого еще лучше. А направление это не задаст большинство, им пофиг.. как-то работает ну и ладно.. Направление в большинстве проектов как раз и задают тех "полтора человека" и именно благодаря им мы и имеет сейчас Друпал, Линукс, Симфони...

[sv2109]

Еще немного и компоненты (табы, таблицы и т.д. будут генериться почти без шаблонов - получится что-то типа Microsoft Foundation classes). Меньше логики в шаблоны! Вот шаблонизатор mustache не зря такой минималистичный.

А теперь аргументируйте и предложите альтернативу.

[EVMedvedev]

Еще в симфони есть компонент Лоадер, который позволяет автоматизировать процесс подключения классов с использованием неймспейсов. Для одного компонента я не стал его подключать, но если будут другие то есть смысл его настроить и все подключать через него.

В этом случае лучше не связываться с внешним кодом, проще свой автолоадер сделать через __autoload или лучше через spl_autoload_register, чтобы стек автолоадеров можно было набирать. Тогда остальные подобные приложения легко будет подключать.

[EVMedvedev]

В обсуждение нужно ввести какую то систему. Иначе будет каша и нулевой результат. Уже сейчас заметны шарахания из стороны в сторону. Может разделить на несколько подзадач? Шаблонизация, контроллеры, бизнес-модели, ядро и т.п.

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

Чтобы оптимизировать контроллеры, структурировать их функции и распределить по иерархии классов. Например в некоторых движках есть многоуровневое разделение функций между классами контроллеров 3-х и более уровней (и это помимо оверайда). ОбщийКонтроллер->ФронтКонтроллер->КонтроллерыСтраницы и т.п.

Возможно для работы с данными стоит ввести группу CRUD классов или что-то вроде xPDO.

Еще не помешает прежде чем делать репозитарии кода создать репозитарий проектной документации, взяв в качестве инструмента например Oracle Fusion Middleware. Если порядка в проекте не будет, то опять получится барахло. Серьезные вещи методом проб и ошибок не пишутся. Нужна стратегия и какое то управление обсуждением.

[EVMedvedev]

Другой вариант развития обсуждения и поиска решений - от проблем и слабых мест. Перечисляем слабые места ОС: шаблонизация, управлением модулями, кастомизация ядра и т.п.; потом определяем источники или причины этих проблем в ОС, ну и наконец предложения по их решению, а потом и кодирование новых решений.

[sv2109]

Другой вариант развития обсуждения и поиска решений - от проблем и слабых мест. Перечисляем слабые места ОС: шаблонизация, управлением модулями, кастомизация ядра и т.п.; потом определяем источники или причины этих проблем в ОС, ну и наконец предложения по их решению, а потом и кодирование новых решений.

Да, все правильно. Я именно с этого и начал. Взял, на мой взгляд. самое слабое место ОС - невозможность что-либо переопределить без правки кода движка. Придумал реализацию системы хуков и событий. И создал для обсуждения именно этой проблемы эту тему. После чего тема превратилась "чего кому не хватает в ОС" :)

Нужно создать отдельную тему для обсуждения всех слабых мест. И каждое такое место обсуждать в отдельной теме, возможно даже в нескольких если есть несколько альтернативных решений.

[EVMedvedev]

Да, все правильно. Я именно с этого и начал. Взял, на мой взгляд. самое слабое место ОС - невозможность что-либо переопределить без правки кода движка. Придумал реализацию системы хуков и событий. И создал для обсуждения именно этой проблемы эту тему. После чего тема превратилась "чего кому не хватает в ОС" :)

Нужно создать отдельную тему для обсуждения всех слабых мест. И каждое такое место обсуждать в отдельной теме, возможно даже в нескольких если есть несколько альтернативных решений.

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

С шаблонами там оказывается предлагается через переопределение функции preRender загружать файл шаблона, править его командами типа pred_replace на лету и потом передавать на рендеринг. Такой аналог vQmod. Но при желании можно вносить таким образом изменения и в шаблоны без их физической в правки.

[EVMedvedev]

Коллеги, для удобства совместной работы сделал такую доку http://smartceo.ru/o.../annotated.html. Если полезно - дайте, знать. Если нет - удалю чтобы место не занимала.Да кстати в этой доке включен оверайд движок и один тестовый класс для оверайда. Дока соответственно по 1.5.4.