Jump to content
sv2109

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

Recommended Posts

Как я все вижу. Нужно:

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

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

Share this post


Link to post
Share on other sites

Хочу послушать кого-то из OC Team. Они на секундочку делают oStore. Ждем.

Share this post


Link to post
Share on other sites

Честно говоря, раздражает полный игнор темы со стороны OC Team :unsure:

sv2109, нет сейчас времени испробовать, но даже если где-то накосячино за энтузиазм надо +100 в карму

Share this post


Link to post
Share on other sites
  • vQmod - говно! Я когда увидел в коде опенкарта что его встраивают - заплевал весь монитор.
  • Нужен и оверрайд и хуки. Глупо выполнять тяжелые расчеты, а потом изменять/удалять результаты...
  • Для реализации обсуждаемого надо делать свою сборку. Уговаривать Дэниеля на изменения ядра - тупая трата времени...
  • Для поддержки своей сборки нужны не только прогеры. Ещё нужны дизайнеры, верстальщики, переводчики и координатор проекта.
  • Готов поддержать эту движуху, но кому такая сборка нужна? На форуме людей понимающих о чем идёт речь в этой теме - полтора человека... остальных всё устраивает, а vQmod вообще вызывает дикий восторг :(.
  • +1 4

Share this post


Link to post
Share on other sites

Yesvik, я тоже как раз думал о проблеме, мол: если делать свою ветку -> нужен супорт. Чтобы был супорт -> своя ветка должна быть популярной.

Я вижу решение в следующем:

Вместо отдельной ветки мы делаем "хак" с зычным названием и source на github. Хак будет модифицировать поведения ядра и он должен быть максимально простой в установке. В идеале это будет одна кнопка "Install" и "Uninstall", соответственно. Сколько строк кода нам надо изменить? Желательно 5-10 в 3-4 файлах - максимум. После этого все аддоны которые мы (=здесь собравшиеся) будем выпускать будут идти в пакете с этим хаком. Таким образом народец постепенно привыкнет, а там глядишь или Даниэль одумается или свою сборку можно будет выпускать.

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

  • +1 1

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Установил чистую 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 закончить хотя бы потому что он скучный.

Share this post


Link to post
Share on other sites

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

$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).

Share this post


Link to post
Share on other sites

Привет, я тоже думал о некой библиотеке, которая позволит сделать разработку под OpenCart максимально простой.

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

Что в нее можно включить тут уже обсуждались. Тут не надо ограничиваться только hook-ами.

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

Например добавление метода

	public function getAll() {
		return $this->data;
	}
к классу Language позволяет конкретно сократить код модулей.

Ибо от

  $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');
в тексте контроллеров уже тошнит.

Можно объединить усилия, и может быть, в перспективе организовать git-репозиторий.

Идея по поводу подключения этой библиотеки: надо сделать ее наиболее минимальной. Т.е. сделать в библиотеке файлик init.php, который бы инклудил все части библиотеки и ее инициализировал. Чтобы подключение библиотеки не менялось от одной ее версии к другой.

form.php

Share this post


Link to post
Share on other sites

  $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');  ?>
  • +1 1

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


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

Share this post


Link to post
Share on other sites

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 :)

  • +1 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
You are posting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.