Перейти к содержанию
sv2109

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

Рекомендуемые сообщения

Час назад на гитхабе появился новый коммит с комментарием "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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне лично не хочется заниматься vQmodописанием, хотя приходится. К сожалению, на данном этапе без vQmod не выходит, но я стараюсь сделать его поменьше. И включение vQmod в релиз пока оправдано. Хуже другое: какую-то фичу легко включить, но потом ведь так просто не выключишь - не дадут.

Надо отдать должное OpenCart 1.5.5.1. В контроллерах больше нет SQL-запросов. Они все через модели. И это, я считаю, уже уверенный шаг к светлому будущему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.