ocmod - зло. мнение

[niger]

3 часа назад, nikifalex сказал:

я уже 2 года пытаюсь донести эту мысль.

Там проблем вагон.

 

p.s. помните, когда еще не было vqmod как прикольно устанавливались обновления.

Сейчас я иногда так и делаю - из ocmod (vqmod) в код. И все работает надежно.

 

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

 

 

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

Открываешь контроллер или вьюху - нихера нет. А на сайте есть. Читаешь модельку, и не понимаешь, откуда же в контроллере эти данные. И несколько раз сталкивался с магией - когда закидываешь xml в vqmod - а на сайте нифига. Ручками код вбиваешь в эти места и все работает. Или не можешь найти среди десятков этих vqmod-ов, нужный файл, который эту магию добавляет. Или когда два или более дополнения, почему то решили одинаково назвать свою переменную, и оба суют её в один и тот же метод контроллера. 

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

[chukcha]

Пиши даниелю!

Хочу getProducts($data, $id='')
а в id подставлять идентификатор процесса
А в событии его ловить

[OCdevWizard]

1 час назад, chukcha сказал:

В какое место?

Ведь они в модели не дают подменить "ядерный" запрос.

пока сыроват этот функционал.

 

я думал отказаться полностью от ocmod но столкнулся с пару моментами, которые так и не удалось решить через events. Так как не вижу смысла юзать events + ocmod (тут или одно или уже второе), остался все же с ocmod. 

[chukcha]

16 минут назад, OCdevWizard сказал:

Так как не вижу смысла юзать events + ocmod (тут или одно или уже второе),

а я пользую оба метода

Если невозможно дотянуться событием - ocmod

[OCdevWizard]

в любом случае за events - будущее. Может и не в этом году, а может и не на следующий, но все же Даниель это допилит. 

[chukcha]

43 минуты назад, OCdevWizard сказал:

но все же Даниель это допилит. 

Если бы он прислушивался, а не выдумывал свой лисапет, то события были бы уже давно в системе.

[sv2109]

1 час назад, OCdevWizard сказал:

в любом случае за events - будущее. Может и не в этом году, а может и не на следующий, но все же Даниель это допилит. 

Я 6 лет назад точно так же думал, ну прям слово в слово :))) еще чуть-чуть.. ну если не в этом году так в следующем.. а потом проходил год, потом еще один, потом еще и еще и еще.. и так 6 лет.

[OCdevWizard]

1 час назад, sv2109 сказал:

Я 6 лет назад точно так же думал, ну прям слово в слово :))) еще чуть-чуть.. ну если не в этом году так в следующем.. а потом проходил год, потом еще один, потом еще и еще и еще.. и так 6 лет.

значит уже пора 

[markimax]

20 часов назад, freelancer сказал:

считаю, что ocmod это костыль

ocmod - это не костыль
Это инструмент СОВМЕСТНОЙ РАЗРАБОТКИ
Такой себе git в opencart

Исходите из этого

[freelancer]

в гите конфликты можно разрешить

[freelancer]

какие хостинги поддерживают git?

[chukcha]

Блин, да причем здесь git
@markimax правильно заметил -

11 минут назад, markimax сказал:

Такой себе git в opencart

Есть золотое правило:

Будьте хорошим соседом

Когда вы создаете какой-либо ocmod, он должен минимально ломать код ядра.
Чтобы пришедший после тебя смог его также безболезненно "ломать"

Но в системе  есть километровые записи, которые сломать лекго

$this->db->query("Многокилометровый запрос")
была бы проще иметь переменную с телом запроса. причем - форматированным

Или еще учитывать trim в правилах
если search - игнорит blank символы
то add - нет, и иногда получается, что код вроде не изменен или нужная позиция есть, но за счет перевода строк код не попадает в search

 

[markimax]

2 минуты назад, chukcha сказал:

Блин, да причем здесь git
@markimax правильно заметил -

Есть золотое правило:

Будьте хорошим соседом

Когда вы создаете какой-либо ocmod, он должен минимально ломать код ядра.
Чтобы пришедший после тебя смог его также безболезненно "ломать"

Но в системе  есть километровые записи, которые сломать лекго

$this->db->query("Многокилометровый запрос")
была бы проще иметь переменную с телом запроса. причем - форматированным

Или еще учитывать trim в правилах
если search - игнорит blank символы
то add - нет, и иногда получается, что код вроде не изменен или нужная позиция есть, но за счет перевода строк код не попадает в search

 

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

[chukcha]

10 минут назад, markimax сказал:

Просто вставляйте вызов вашей модели или контроллера, который обработает данные, а не целую простыню кода

ДА!

[freelancer]

как защититься от кретинов, которые пишут ocmod'ы ?

[Tom]

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

[chukcha]

6 минут назад, freelancer сказал:

как защититься от кретинов, которые пишут ocmod'ы ? 

а ты пробовал защищаться от шаблоноПейсателей?

[sv2109]

1 час назад, markimax сказал:

ocmod - это не костыль
Это инструмент СОВМЕСТНОЙ РАЗРАБОТКИ
Такой себе git в opencart

 
Я этот перл  даже заскринил)))  от автора строк,  о том, что "опенкарт самый лучший движок и фреймворк с самой лучшей архитектурой"

Ocmod - это костыль и зло. Точка. 
Да, если! правильно и очень осторожно, только в самых крайних случаях его использовать и это будут делать вообще все разработчики то это сможет уменьшить к-во конфликтов. НО это только уменьшит к-во конфликтов может на 30%, может на 50%, но их все равно останется очень много, в разы больше, чем на системах, которые этот костыль не используют. Потому что и сам опенкарт написан так, что часто просто необходимо делать изменения через замену и далеко не все разработчики прислушаются к этим рекомендациям, особенно создатели тем, где в ocmod по 1000 строк кода.. и так далее. 

О чем вы вообще спорите? Ocmod просто берет кусок какого-то кода и тупо втыкает его в какое-то место в движке.. при этом ни разработчик, который вставил свой код до этого в тоже самое место ни разработчик который вставит свой код после этого знать ничего не знают о том, что кто-то этот код изменили, и тут не обязательно вставлять через замену, можно просто вставить до или после но добавить какое-то условие (которое необходимо даному модулю) которое поломает код другого разработчика.. Избежать подобных конфликтов просто невозможно, даже если все разработчики будут очень правильно использовать ocmod (чего никогда даже близко не будет)

 

1 час назад, markimax сказал:

Просто вставляйте вызов вашей модели или контроллера, который обработает данные, а не целую простыню кода

 

Тему создал @freelancer я так понял, что он пишет фильтр и ему нужно изменить SQL запрос получения товаров getProducts и  как это сделать подключив свою модель? Нет, сделать конечно можно и даже очень просто - пишем свою модель, скопировав туда весь код из getProducts, изменяем ее как нам угодно и подключаем в своем контроллере и что? А то, что таким методом вместо того, чтобы избавиться от конфликтов мы их наоборот наплодили целую кучу, потому что на сайте может быть установлен с десяток модулей, которым тоже нужно изменить метод getProducts (а это один из самых изменяемых методов в движке) и которые или изменят оригинальную версию и работать ничего конечно же не будет, потому что контроллер будет вызывать модель фильтра, а не модель товара, или пойдут по тому же пути и создадут свои модели и получится полная жесть.. Вот вам и супер классный инструмент "совместной" разработки на супер классной архитектуре.. 

Я о том, что ocmod и конфликты это почти слова синонимы и избавится от конфликтов используя ocmod просто невозможно,  в смысле вообще. При правильном подходе (которого никогда у всех не будет) можно немного знизить к-во конфликтов но это максимум.



 

[freelancer]

6 минут назад, sv2109 сказал:

Тему создал @freelancer я так понял, что он пишет фильтр

проблема гораздо шире

[markimax]

21 минуту назад, sv2109 сказал:

Совершенно не понял вашего сарказма и он не уместен и не обоснован
Если у кого то кривые руки и пишут кривые  модификаторы, то причем здесь "лопата"
ocmod - это инструментарий совместной разработки, "лопата"
Не было бы vqmod (вот это костыль был) или ocmod (стандарт) opencart бы не получил такого распространения
Можете не использовать ocmod - ваше право. Архитектура opencart построена на овердрайве и позволяет другие варианты. Овердрайвите тогда, работайте с событиями и т п. Только тоже надо с умом это делать. Поймите наконец, "лопата" не виновата что руки-крюки у кого то
Насчет запроса.
А в чем проблема его разобрать перед выполнением? Ведьма например так и делает в MFP

[chukcha]

7 минут назад, markimax сказал:

А в чем проблема его разобрать перед выполнением?

для getProducts - не проблема

а для

    public function getProduct($product_id) {
        $query = $this->db->query("SELECT DISTINCT *,

Уже проблема
 

[markimax]

Только что, chukcha сказал:

для getProducts - не проблема

а для

    public function getProduct($product_id) {
        $query = $this->db->query("SELECT DISTINCT *,

Уже проблема
 

В DB перехватывать
Хотя согласен - это конечно треш
Надо бы
 

$sql = .....

$query = $this->db->query($sql);

 

[vier]

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

в своем модуле я так и сделал - создал собственный общий запрос по обработке товаров для категорий/производителей/акций, и с подключением по потребности доп.запросов (уже готовых, но подумываю и о создании произвольных, по такой же логике, как использую в своем коде, и как написал markimax)

 

так же считаю большое зло подключать модель в метод, который в свою очередь попадает в цикл, как например function getProduct(), который обрабатывается в function getProducts()

foreach ($query->rows as $result) {
	$product_data[$result['product_id']] = $this->getProduct($result['product_id']);
}

 

[AlexDW]

в сравнении с развитой системой событий и конструктором запросов - может ocmod и зло

но при их отсутствии, сам по себе ocmod - отличное решение

 

достаточно вспомнить эру "до vqmod", с портянками инструкций по ручному изменению файлов

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

 

проблема не в ocmod, а в тех, кто его использует непродуманно и не заботясь о совместимости

[vier]

1 час назад, AlexDW сказал:

в сравнении с развитой системой событий и конструктором запросов - может ocmod и зло

но при их отсутствии, сам по себе ocmod - отличное решение

если это про это зло -

3 часа назад, vier сказал:

так же считаю большое зло подключать модель в метод, который в свою очередь попадает в цикл, как например function getProduct(), который обрабатывается в function getProducts()

то это я не про ocMod писал, и тоже, как и Вы не вижу пока реальных замен ocMod`у.