Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

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


Recommended Posts

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

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

  • +1 1
Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

Надіслати
Поділитися на інших сайтах

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

Drupal, Symfony, ZF

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

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

  • +1 1
Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

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

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

  • +1 3
Надіслати
Поділитися на інших сайтах

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

Если мне в Друпале в своем модуле нужно создать например новый пункт меню, то я сделаю это с помощью готового хука. после чего я буду на 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 интерфейс сделать не получается.

  • +1 1
Надіслати
Поділитися на інших сайтах


Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.