vqmod похоже скоро окажется в ядре.. facepalm

[sv2109]

Час назад на гитхабе появился новый коммит с комментарием "started adding my own version of vqmod." посмотреть на него можно по этой ссылке https://github.com/opencart/opencart/commit/7a64c342ee3d551f5c3d40c3c4df0cea2ea17f91

Похоже что создатели опенкарта все-таки решились на добавление vqmod в ядро. У меня просто слов нету...

[freelancer]

в каком то смысле упростит жизнь

[pashast]

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

[sv2109]

Это хорошо для пользователя, которому не придется искать vqmod на стороннем сайте и устанавливать его итд.

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

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

[freelancer]

не думаю что хуки и прочее сделают движок лучше(по крайней мере я не видел реализаций). сейчас у OpenCart низкий порог вхождения как раз из-за простоты

[sv2109]

не думаю что хуки и прочее сделают движок лучше(по крайней мере я не видел реализаций)

Drupal, Symfony, ZF

сейчас у OpenCart низкий порог вхождения как раз из-за простоты

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

[freelancer]

Drupal, Symfony, ZF

сюда же можно добавить joomla, wordpress или mediawiki. зачем усложнять?

[freelancer]

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

у меня конфликты были только с шаблонами. все шаблоны, которые я пересмотрел можно было сделать совместимыми с дефолтным (кроме shoppica, она вне конкурентов)

да и не думаю что хуки спасут от конфликтов

[sv2109]

да и не думаю что хуки спасут от конфликтов

Не говорите ерунды.

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

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

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

[EVMedvedev]

Не говорите ерунды.

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

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

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

Да что вы его убеждаете. Он кроме OC похоже ни чего не знает, вот и считает его идеалом. Вот еще пример говнокодинга в OC.

public function getPath($category_id) {

$query = $this->db->query("SELECT name, parent_id FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' ORDER BY c.sort_order, cd.name ASC");

if ($query->row['parent_id']) {

return $this->getPath($query->row['parent_id'], $this->config->get('config_language_id')) . $this->language->get('text_separator') . $query->row['name'];

} else {

return $query->row['name'];

}

}

По сути часть HTML кода формируется этим $this->language->get('text_separator') и даже не в контроллере ( я про шаблон уже даже не говорю), а в модели (функция из admin/catalog/model/category.php. Вроде мелочь, но таких мелочей в OC немеряно.

Я столкнулся с этим когда начал делать сервис для группового редактирования цен товаров. Еще наступил на грабли разделения моделей на админку и фронт. В результате чтобы добиться желаемого без изменений кода OC и без использования vqmod вынужден был объединить модели из фронта и админки в одном скрипте загружая фронтофисную модель товара как обычно, а админовую через тот самый var:// с подменой имени класса. Во всех нормальных движках файл модели на один объект один единственный и используется и в бэк и во фронт.

В общем редактор цен то я сделал, работает в демо режиме. Хотел добавить сюда http://smartceo.ru/index.php?id=76 чтобы функции были доступны не только для Prestashop, но пока из-за бестолковостей ОС более-или менее приличный REST интерфейс сделать не получается.