sv2109
-
Публікації
3 664 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Коментарі блогу, опубліковані користувачем sv2109
-
-
On 10/4/2023 at 3:31 PM, markimax said:
І де зараз друпал? Хтось чув? Ауу... Де Magento?... Ауу...
Якшо ви особисто з якимось двіжком не працюєте то це зовсім не означає що він мертвий))
Ось наприклад по друпалу, він зараз десь у 5 разів популярніший за опенкарт!
https://trends.google.com.ua/trends/explore?date=today 5-y&q=%2Fg%2F11b5m9hl85,%2Fm%2F01641s&hl=uk
Але масово ви про них і не будете чути, бо і друпал і магенто це зовсім інший сегмент сайтів, це корпоративні сайти, на друпалі колись працював сайт білого дому, не знаю як зараз + різні дуже великі сайти та портали, напр. redhat.com, europa.eu ітд. на магенто розробляють магазини типу allo.ua та інші подібні та дуже великі магазини.
Розробники там беруть до 200 і навіть більше $ за годину! і за один день заробляють більше, ніж середньостатистичний розробник під опенкарт заробляє за місяць))
Просто це корпоративний сегмент і туди дуже тяжко пробитися якомусь одному фрілансеру, там заказчики це дуже великі контори які навіть дивитися у сторону фрілансерів не будуть, вони краще заплатять декілька десятків а то і сотень тис.$ якісь великій софтверній фірмі, ніж в десятки разів менше, але якомусь фрілансеру..
-
1
-
-
On 10/3/2023 at 3:05 PM, Vladzimir said:
Опенкарт добре обійшовся б і мікрофреймворком. Наприклад цим http://fatfreeframework.com
згоден, саме з цим я не працював, але колись працював з першими версіями Codeigniter -а так він навіть по синтаксису дуууже сильно нагадує опенкарт, мені навіть здається що на я етапі створення опенкарту Даніель просто злизав частину коду з цього фреймворку.
Але в плані фреймворка опенкарт не дотягує навіть до перших версій Codeigniter-а.. що вже говорити про інші більш сучасні фреймворки.
А так, да, взяти якийсь дуже простий фреймворк, перенести ядро на нього і дописувати тільки сам функціонал самого магазину і взагалі не паритися на рахунок ядра, над яким працюють інші розробники, постійно його вдосконалюючи, випускаючи нові версії, виправлячи баги, добавляючи нові функції ітд.
Цим шляхом до речі у свій час пішов Друпал, раніше десь до 6,7 версії у них все працювати на своїх власних велосипедах і вони витрачали реально купу часу щоб все це підтримувати, потім плюнули та перевели весь Друпал на симфоні, скинувши зі своїх плеч величезний об'єм роботи, бо це все вже і так реалізовано та підтримується величезною спільнотою симфоні. І в результаті від цього всі тільки виграли.-
1
-
-
On 10/4/2023 at 12:30 PM, markimax said:якщо нормально написаний ocmod - ніяких конфліктів не буде взагалі)
а то я мабуть 10 років з якимось іншим опенкартом працюю)))
при використанні модифікаторів конфлікти будуть завжди! Причому їх буде дуже багато. Бо модифікатор змінює код самого опенкарту. І питання тут не у тому правильно написаний той модифікатор чи ні, конфлікти будуть у будь-якому випадку бо модулі пишуть різні розробники і один взагалі нічого не знає і не може знати що у голові у іншого...
Я пишу свій модуль і прив'язуюся в модифікаторі до якогось конкретного куска коду в стандартному опенкарті, добавляю свій код після нього. І все працює, бо у стандартному опенкарті цей код є.
А до мене якийсь інший розробник змінив цей кусок коду на інший чи дописав щось своє, бо для його модуля саме це треба було зробити, і що буде? мій модуль вже не знайде потрібний код та не добавить свій код після нього. І що це як не конфлікт? маємо помилку і або один модуль не буде працювати або два. Або і ще гірше - два модуля будуть працювати і жодних помилок не буде, але логіка роботи зміниться і наприклад десь у корзині якась ціна буде нараховуватися неправильно.. і подібні помилки взагалі дуже тяжко виправляти бо все вроді працює і в логах чисто..
Так ще не розповідайте басні, що ніяких конфліктів не буде, якщо у магазині встановлено декілька десятків модулів (практично у кожному магазині так) і кожен із модулів вносить десятки змін у код самого опенкарту + ще встановлена якась тема тиду джорнал яка сама по собі переписує половину опенкарту і в результаті отримуємо опенкарт, встановити якийсь новий модуль на який ще те задоволення.. сидиш і тупо виправляєш конфлікти бо все не так як треба.-
3
-
-
On 10/3/2023 at 11:27 AM, Vladzimir said:
Потрібен не білдер, а Data-Mapper, з лінивою загрузкою, наприклад як цей https://github.com/ikkez/f3-cortex. Тоді ніякі джоіни не потрібні. І зникає оверхед від запитів у циклах і т.і. І розширювати цю систему буде дуже легко.
Дуже спірно, як на мене.
Data Mapping це по суті ORM, ORM це дуже крута штука, згідний, але для опенкарту це буде занадто складно, особливо зараз. Зараз люди звичайний конструктор запитів не можуть прийняти бо для них це заскладно, то як вони повинні прийняти цілу ORM яка буде значно складнішою? + вона також буде працювати повільніше, бо це ще один великий шар абстракції. До ORM потрібно дорости і опенкарт як на мене ще взагалі не доріс що цього.
ORM дуже зручна якщо мова йде про не складні запити, але коли з'являються зв'язки, особливо зв'язки many to many де в ідеалі потрібно створювати ще одну проміжну pivot таблицю і працювати через неї, щоб побудувати цей зв'язок то це значно ускладнює все. Взяти наприклад таблицю товару в опенкарті (яка пов'язана ще мабуть із десятком інших таблиць, а ті ще з іншими) і як це все перенести на ORM? Перенести то можна, але що в результаті вийде і як воно потім буде працювати по швидкості? Та і рішення яке вийде буде ніяк не простим.
Ну і + ORM це штука, яка добре працює у великих системах, де крім самої ORM є ще дуже багато всього (різні міграції, фабрики, кешування, події, інтеграція із шаблонізатором ітд.) і все працює як одне ціле, наприклад в Laravel я через ORM отримую колекцію (по замовчуванню отримується тільки поля основної таблиці, без зв'язків, щоб зробити запит швидким), передаю її у шаблонизатор, там в циклі прохожуся по якомусь зв'язку цієї таблиці і все працює (знову ж таки, потрібно добре розуміти як це все працює під капотом, щоб розуміти скільки запитів до бази при цьому буде створено). А не так що взяти одну ORM і всунути її у опенкарт бо це круто і правильно.
У той час як конструктор запитів до бази даних, так, він не такий функціональний, але він і набагато простіший, легший в освоєнні та швидший. І для опенкарт на зараз як на мене підійшов би просто ідеально, як заміна сьогоднішнього підходу коли всі SQL запити тупо пишуть вручну.. Зараз це була б золота середина між голими запитами як зараз та ORM, яка накладає свої обмеження та складнощі.
Пізніше коли б всі звикли до конструктора то можна було би подумати щоб впроваджувати щось більш складне та функціональне, але на зараз як на мене це зайве.
Якось так, моя досить аргументована позиція)) -
On 10/2/2023 at 3:31 AM, MaxD said:
Якраз Opencart простий в освоєнні та швидкий тому, що в ньому по суті немає івентів і додаткових рівнів абстракцій, а просто код, який читаєш, розумієш і міняєш.
1. я вам вище написав як працюють події - там все дуже просто, після виконання якоїсь події запускається якийсь метод модуля, все. Що тут складного? Якби була нормальна документація зі всіма подіями, до яких можна підключитися та реальні приклади роботи з ними то освоїти події можна максимум за 1 день це якщо комусь ну дуже тяжко дається щось нове, а так то їх можна вивчити за півгодини.
2. до чого нас довела "простота" опенкарту ми всі вже прекрасно бачимо, до ручки вже дійшли. Далі по суті 2 шляхи - або почати щось змінювати вже зараз (точніше це потрібно було робити ще декілька років тому) або весь опенкарт просто приречений, він і надалі буде занепадати поки не загнеться остаточно.. нажаль. Бо у 2023 році писати SQL запити вручну а потім ще й змінювати це все за допомогою модифікаторів це.. гм.. пц. короче.
On 10/2/2023 at 3:31 AM, MaxD said:Порівняйте час освоєння розробки для Opencart та Prestashop/WooCommerce.
я ж ніде не написав, що опенкарт потрібно перетворити у престашоп чи вукомерс, до речі трохи працював і з тим і з тим і код там просто жесть..
Задача якраз таки залишити всю простоту опенкарта при цього добавити функціоналу та зменшити к-сть конфліктів.
Якщо замість sql запиту на півсторінки буде один зрозумілий $sql->select('*')->where('...')... при чому не потрібно буде вручну писати весь sql код, не потрібно буде скрізь писати префікс таблиці, не потрібно буде екранувати всі дані (бо конструктор це все зробить за тебе) і саме головне будь-який sql на сайті можна буде дуже легко змінити при чому без конфліктів з другими модулями у майбутньому то де тут ускладнення? Як на мене то все навпаки стане простішим. І при чому тут престашоп? У нас буде той самий опенкат, тільки з яким працювати буде в рази комфортніше і к-сть конфліктів буде в десятки разів меншою, якщо все буде працювати через події.
Тут якраз таки навпаки ми отримаємо велику перевагу бо по якості та функціоналу опенкарт стане багато у чому не гіршим за конкурентів, а у простоті освоєння в рази простішим.
А якщо тупо викинути події бо комусь вони знаються надто складними та повернутися назад до модифікаторів - то це тупо шлях в нікуди і якщо років 10-15 тому на це ще можна було якось дивитися то зараз, то у 23 році це жесть, це архітектура, яка вже мінімум років 10 як застаріла.-
5
-
-
Ух, яку тему пропустив))
Якщо ще не пізно то вискажу свою думку, яку вже не раз висловлював тут.
Взагалі такий проект потрібно починати ніяк не із стилів кодування, це якраз можна зробити і потім.
Головне - це концепція, що у даної збірки буде такого, що буде якісно відрізняти її від теперіншього опенкарту, який докотився все "до ручки"..
І зробити це дуже не складно - за основу беремо недоліки опенкарту (які ми всі дуже добре знаємо) та просто їх виправляємо, залишивши при цьому всі переваги.
А не просто переписати все на статичні класи і все, це не вирішить жодних проблем. Це те саме що по суті робить сам Даніел - замість того щоб виправляти глобальні проблеми в коді добавляє нові шаблонізатори та змінює версії бутстрапу. Як на мене це всеодно, що починати ремонт у старій хрущовці не з заміни сантехніки, електрики, штукатурки итд. а з переклеювання шпалер та вкладання нової плитки в у санвузлі, яку будуть ложити на старі гнилі та іржаві труби та стару штукатурку - зовні може буде і гарно, але не це ж пц повний..
Які переваги у опенкарта:
1. Немала популярність, вона знижується, але на ньому все ще працює дуже багато сайтів
2. Дуже багато розробників які з ним працюють і на яких по суті все і тримається і які повинні бути дуууже зацікавлені щоб опенкарт розвивався і далі
3. Сам двіжок дуже простий в освоєнні та роботі та дуже швидкий, я бачив магазини на опенкарти де було більше мільйона товарів!
4. Величезна к-сть модулів, плагінів та тем
5. (можете доповнити)
Недоліки (і їх також вистачає)
1. За розвиток всього двіжка відповідає аж одна людина, яка робить виключно те, що сама вважає за необхідне. На мою думку у Даніела просто не має необхідного технічного досвіду, щоб зробити з опенкарта нормальний двіжок. З нього б вийшов дуже гарний та відповідальний міддл розробник, який би працював з вже спроектованою архітектурою, але спроектувати велику систему самостійно він тупо не може.. З самого початку у мене таке враження що основу двіжка він десь злизав з якогось фреймворка (мені код дуже нагадує перші версії codeigniter) а далі вона взагалі не розвивається. Тобто сам зробити не може, а іншим не дає..
2. Дуже жахливе відношення Даніела до інших розробників, коли для кожної нової мінорної версії двіжка потрібно писати нову версію модуля, бо там змінилася якась дрібниця типу створення посилань чи ще щось. Коли для кожного модуля потрібно писати гору html коду а потім його щей переписувати під кожну нову версію твіга чи бутстрапа. Коли за 15 років існування двіжка все ще немає нормальної системи розширень. Коли будь-які пропозиції та побажання щось виправити тупо ігноруються.. на і так дал. Тобто, розробників на яких все тримається тупо посилають подалі з їхніми проблеми.
Писав про це ось тут3. Примітивне ядро самого двіжка. Всі говорять, що опенкарт простий і це його плюс, ні, він, не простий - він примітивний і це не плюс, а насправді величезний мінус. І те, де опенкарт опинився зараз це якраз і результат цього.
Відсутність нормальної системи розширень. Гарна система розширень це по суті основа, фундамент любого двіжка. Бо навіть якщо там буде дуууже примітивний функціонал, то маючи гарну систему розширень інші розробники самі все допишуть та щей зароблять на цьому продаючи різні розширення.
Я вважаю і багато розробників цю думку підтримують що система модифікацій vqmod/ocmod це дійсно зло. Цей підхід суперечить багатьом фундаментальним принципам програмування. Наприклад принципи SOLID, другий принцип O - принцип відкритості-закритості, який говорить що програмі рішення повинні бути відкриті для розширень та закриті для модифікацій коду, тобто всі розширення повинні робитися через інструменти, які при цьому не змінюють програмний код! В опенкарті ж це не просто робитися як виключення, на цьому побудована вся! система розширень самого двіжка.. Це просто вибух мозку для мене бо це породжує просто нереальну кількість конфліктів та проблем. І в результаті з цього двіжка втікають як самі розробники, так і прості користувачі, яким постійно приходиться стикатися та виправляти якісь помилки. Для чого їм це якщо зараз є десятки сервісів, де вони можуть в пару кліків мишки створити свій магазин взагалі без знань програмування, і не просто створити, але і розширити його модулями та темами. І при цьому їм не прийдеться виправляти жодної помилки! І це на мою думку головна проблема опенкарту! (як мінімум одна із головних) і її потрібно вирішувати в першу чергу, без цього просто неможливо створити нічого якісно кращого за теперішній опенкарт.
Як це можна виправити? Добавити систему Подій (Events)
Вони взагалі не складні! Вся суть у тому, що коли у системі настає якась подія то до чи після неї запускається якась функція модуля. Все. Що тут складного? Просто Даніел спочатку добавив події без жодної документації, потім постійно у кожній новій версії їх змінював змінюючи і синтаксис і самі події, а потім взагалі забрав модифікатори, коли за допомогою подій не можна було вирішити великої к-сті необхідних задач.. і що в такій ситуації робити розробникам??
Самі події це дуже простий та елегантний концепт, це готовий патерн програмування, який використовується величезною к-сть інших двіжків, фреймворків та систем ітд. І скрізь це працює. Так чому ж це не працює в опенкарті? Тому що для впровадження цього інструменту мало створити клас Event.. тут потрібно змінювати сам двіжок, щоб він їх у повній мірі підтримував. Щоб через Events можна було вирішити не половину всіх можливих задач, а максимально набализитися до 100%, покриваючи фактично всі можливі задачі.
Як це можна зробити не буду повторюватися, писав тут
Ось вам готовий варіант двіжка, концепт, який буде якісно відрізнятися від існуючого опенкарта (а не тупо скопіює всі його проблеми не вирішивши їх, замінивши об'єкти на статичні класи..) і на який я б наприклад з радістю перейшов замість сьогоднішнього опенкарту, який вже якщо често в печінках сидить через свої баги, конфлікти, помилки та жахливе ставленням Даніела до всіх розробників.-
6
-
-
38 минут назад, SooR сказал:
Проще же WHERE foo = 'bar' AND baz = 3.
А теперь другому модулю нужно изменить этот запрос, добавив новый джойн и какие-то свои новые условия. И что делать? Изменять все через модификатор?
а потом третьему модулю нужно добавить свой новый джойн и свои условия, он пытается сделать этот тоже через модификатор и все, или не работает один модуль и автору нужно вручную ковыряться в коде чтобы исправить конфликт или другой или ошибка 500 и вообще ничего не работает или что еще хуже код может работать но логика работы будет другой, не такой как задумывалось, потому что предвидеть эти моменты как другие модули изменять один и тот же кусок кода невозможно.
Конструкторы усложнят код - да, не сильно но усложняют.
Но они дают преимущества, которые с лихвой перекрываю это.
Одно из самых больших преимуществ - возможность использовать систему Событий для изменения любого! запроса в движке. И при системе событий и 2 и 3 и даже больше модулей могут изменить один запрос и конфликтов при этом будет в десятки раз меньше, так как все будет делаться через понятный api а не через str_replace или preg_replace.
-
1
-
-
4 часа назад, chukcha сказал:
ага, еще и по табам разбить
именно для табов подобный подход будет исключительно полезен, так как
тот, кому хоть раз приходилось делать форму в которой были табы с двойной или даже тройной вложенностью, те понимают какой это ад, я когда-то создавал с тройной вложенностью, был верхний горизонтальный, потом вертикальный и потом еще табы для разных языков. Эту форму я писал несколько дней. И если в ней вдруг забыть случайно закрыть какой-то див или удалить случайно что-то, то все, можно и пол дня искать причину..
В конструкторе же можно легко сделать
'tab' => array('name' => 'Tab1',
'fields' => (...),
)
или'tab' => array(
'name' => 'Tab1',
'tabs' => (...)
)
И все работает, и можно делать хоть 2 вложенности хоть 3 хоть даже больше.
4 часа назад, chukcha сказал:Вам удобно? пользуйте свой
вы или плохо читали пост или не поняли его суть.
Суть не в том, чтобы каждый использовал свой собственный инструмент, потому что толку с этого не будет никакого. Мало того, это будет настоящий ад потому что придется изучать синтаксис каждого модуля отдельно чтобы понять как с ним работать. + вопросы совместимости, производительности, конфликтов итд.
Нужно что бы это было в самом движке, только тогда можно сделать систему Событий, которая позволит со всем этим работать и сможет дать расширяемость движка и уменьшение конфликтов.
Опять же если какому-то разработчику будет не удобно работать напр. с конструктором запросов или форм, то он по прежнему сможет писать код по старому и он будет работать.
-
3 часа назад, SooR сказал:
Изменения больше косметические, вот одно из них:
$data['add'] = $this->url->link('customer/customer|form', 'user_token=' . $this->session->data['user_token'] . $url);
То есть вызов метода по ссылке через вертикальную черту. Зачем? Не знаю, визуально отделить файл/класс от метода. Стоит ли это изменение совместимости с модулями - однозначно нет.
Вообще обновления мажорных версий больше выглядит как руководство к "правильному" кодингу. Даниель решил что так будет правильней, красивей, значит пишите так и привыкайте к новому. Вместо наращивания функционала все снова уходит в организацию кода, файловой структуре. Короче, неоправданный головняк.
да, тоже видел)
а чтобы разработчики не скучали папку дополнений перенесли в другое место и бутстрап 5 добавили вместо 4, визуально мало что поменялось, но если посмотреть по коду любого модуля..
вместо
class="pull-right"
class="float-end"
вместо
<ul class="breadcrumb"><ol class="breadcrumb">
вместо
<li><a href="{{ breadcrumb.href }}">{{ breadcrumb.text }}</a></li>
<li class="breadcrumb-item"><a href="{{ breadcrumb.href }}">{{ breadcrumb.text }}</a></li>
вместо
<div class="panel panel-default">
<div class="card">
ну и еще несколько десятков! подобных мелочей и нужно будет каждый модуль теперь пол дня переделывать чтобы получить по сути тот же самый вид, только уже под 5 бутстрап! -
35 минут назад, Vladzimir сказал:
И если Даниэль не может сам написать нормальное решение, то почему не использовать готовое?
1. Потому что он никак не считает свое творение ненормальным решением, как раз таки наоборот он считает что создал чуть ли не идеальное решение, аналогов которому не существует во всем мире.
2. Потому что он вбил себе в голову что весь код должен быть максимально простым и чем проще, тем лучше, потому что тогда движок будет очень популярным. И думать так очень удобно для самого Даниела, потому что написал ядро 15 лет назад и все, обновляй версии бутстрапа много лет. А на все вопросы "а почему в движке нету ххххх" есть один универсальный ответ - "потому это нарушает философию движка". Поэтому все предложения добавить сюда что-то новое рубятся под корень ибо не положено, это будет слишком сложно..-
1
-
-
17 минут назад, Blast сказал:
я же правильно понимаю, что такой подменой ваш модуль шлет лесом любые изменения, внесенные модификаторами в стандартные методы getProducts, getInformations и т.д.?
по идее не только модификаторами но даже событиями из других модулей, так как эти события привязаны с оригинальному роуту, а не к новому. Если это так, то ломается вообще все.
12 часов назад, MaxD сказал:Согласен, это достаточно странно, но в принципе ничего сложного:
if (!$code) $code = file_get_contents(DIR_TEMPLATE . $this->registry->get('config')->get('template_directory') . $route . '.twig');
подобные вещи по любому должны быть в самом движке, должна быть одна точка входа, иначе завтра логика загрузки может измениться и этот код работать не будет. Как измениться? Например если в 4 версии уберут модификаторы и оставят недоделанные события то каждому разработчику придется или изобретать какой-то свой велосипед для изменения файлов движка или загружать в движок какой-то модуль аналог модификаторов (да и не факт что он будет один а не несколько) и этот файл шаблона потом может лежать по разным путям. И что тогда?
Должна быть одна точка входа, тогда ее и изменить просто и работать с ней более удобно.
Вот почему бы загрузку шаблона не закинуть вот сюда?
catalog/controller/event/theme.php
если в базе есть код шаблона (измененный через редактор) то загрузить его, если нету то загрузить из файла.
12 часов назад, MaxD сказал:Меня в этой всей истории смущает другое. Мне кажется, что отличительной особенностью Opencart по сравнению с Wordpress/Prestashop/Magento было то, что можно было просто читать и менять код движка, быстро добиваясь нужного результата. Низкий порог входа, прямолинейное изменение и все такое. А с переходом на события становится "как у всех", когда для даже небольшой модификации надо сильно много думать и курить кучу доков.
Мне кажется, что это иллюзорная простота. Когда сначала - да, открыл модификатор, добавил пару правил и все работает. Быстро и просто. Но потом это вылазит в огромное к-во конфликтов которые исправлять приходится разработчикам, разбираясь в этом все кошмаре. И приходится иногда весь день тратить на всевозможные конфликты. И если на сайте установлено пару модулей то еще нормально, а если там десятки модулей + куча кастомного кода + еще тема в довесок на подобие какой-то джорнал и все, атас, попробуй найди причину почему что-то не работает?
С другой стороны события они более сложны сначала (хотя если все нормально сделано, а не такая уродская пародия как сейчас, и есть нормальная документация то все изучается за буквально пару часов), но потом к-во конфликтов уменьшается в десятки раз. Ты просто пишеш код и он работает! представляете, так оказывается можно!
И не зря все другие движки переходят на события или хуки или их аналоги, потому что они намного более предсказуемы и дают возможность различным разработчикам писать дополнения которые не конфликтуют между собой.
Похоже что уже даже Даниел это понял, так как не зря же он начал разрабатывать события если и модификаторами можно было все что нужно сделать? И не зря же в 4 версии модификаторы хотят удалить. -
46 минут назад, optimlab сказал:
А что подменой метода из модели нельзя? Или вы про sql-запрос в самом методе?
подмена есть, но подмена это возможность заменить что-то только одному модулю. А что если одну модель напр. модель товара нужно заменить десятку модулей, тогда как?
Да, я об изменении самого sql запроса.47 минут назад, optimlab сказал:В смысле? Я что-то пропустил. Теперь можно менять не сам отрендереный html, а сам код twig?
можно, как выше уже написали, но и одно и другое это ужасный костыль, даже хуже чем модификаторы, описал недостатки выше.
-
6 минут назад, MaxD сказал:
Ну это тривиально. В обработчике события, если передали пустой $code - в него надо самостоятельно загрузить оригинальный файл шаблона. А если не пустой - то работать, с тем что передали
как вариант, но все равно это очень кривое решение
1. как я могу быть уверен что если $code не пустой, что другой модуль до меня загрузил именно нужный мне файл? а не какой-то свой или что-то совсем другое? Ведь загрузить можно что угодно. Или что если я что-то изменю то кто-то другой после меня не загрузит свой вариант шаблона и не затрет все мои изменения?
2. каждому модулю вручную загружать код шаблона из файлов не имея вообще никакого апи и инструментов для этого? Я поэтому и не увидел этот вариант что не мог подумать что подобная дичь доступна в движке, ведь это 100% работа движка работать с файлами шаблонов, а не модулей.
А после загрузки что? каждому модулю так же вручную изменять его с помощью чего? str_replace и preg_replace?...
Да и чем этот вариант принципиально отличается от варианта с модификаторами? Там в шаблоне искали какой-то код и заменяли его на свой, создавая при этом кучу конфликтов и тут точно тоже самое, только если в модификаторах все делал сам движок по инструкциям в xml файле + было кеширование и возможность нормальной отладки, то тут каждый модуль будет это делать по своему через свой код и свои велосипеды (при чем код этот вообще может быть закрыт) в котором потом фиг разберешься, без кеша и возможности отладки.. -
Правда не могу до конца понять как работает
ArrayLoader в твиг, там передается массив где ключ это файл, а значение - это код из обработчиков событий. -
1 час назад, chukcha сказал:
легко
как? можно вызывать какой-то свой код До выполнения любого контроллера и После него.
И первый и второй практически бесполезны.
Но изменить сам контроллер никак нельзя, какую-то логику внутри. -
11 минут назад, MaxD сказал:
Так вот я как-раз говорю, что в 3.0.3.5 добавили возможность изменять шаблон:
// Template contents. Not the output! $code = ''; // Trigger the pre events $result = $this->registry->get('event')->trigger('view/' . $trigger . '/before', array(&$route, &$data, &$code)); ... $output = $template->render($this->registry->get('config')->get('template_directory') . $route, $code);
Если $code не пустой, то он используется вместо фактического текста шаблона. Получается, что можно модифицировать шаблон в обработчике события, и несколько дополнений, которые вносят изменения в один и тот же .twig, могут вполне себе уживаться.
Ну я это видел. Но в первом случае в before $code - вообще пустой. Если кто-то не положит туда что-то из своего обработчика. Это не оригинальный шаблон, который можно изменить.
А во втором случае смотрю по коду в 3037
в библиотеке шаблонизатора
public function render($filename, $code = '') { if (!$code) { $file = DIR_TEMPLATE . $filename . '.twig'; if (is_file($file)) { $code = file_get_contents($file); } ... } // initialize Twig environment $config = array(...); try { $loader = new \Twig\Loader\ArrayLoader(array($filename . '.twig' => $code)); $twig = new \Twig\Environment($loader, $config); return $twig->render($filename . '.twig', $this->data); } ... }то есть этот $code, который сформирован обраточиком (или обработчиками) модулей просто заменяет оригинальный код шаблона.
То есть изменить оригинальный код шаблона все равно никак нельзя.
-
1 час назад, chukcha сказал:
getProductcs
точнее - вызов контроллера thumb, в который передаются
https://github.com/opencart/opencart/blob/d1546a0970976498603fa27d76fe8fdc065fdcbd/upload/catalog/controller/product/category.php#L205Но Даниель противится передать туда сырой product_info ($result);
Да, это кстати бы решило немало проблем, так как можно бы было через событие после выполнения модели добавить в результат какие-то свои данные и они автоматически бы попали в шаблон минуя контроллер. Иначе теперь нужно как-то их прописать в контроллере, а такой возможности тупо нету и зачем тогда их изменять если потом с помощью событий сделать с ними вообще ничего нельзя?
И это все при том, что события существуют начиная со второй версии движка (если не ошибаюсь) а уже на подходе 4-я.. -
7 часов назад, MaxD сказал:
По поводу "как мы будем жить без OcMod"... Только на днях заметил, что начиная с 3.0.3.5 есть событие до загрузки файла шаблона, которое позволяет его изменить или поставить свой. Видимо это и ответ, причем не самый плохой
Там есть 2 события, а не одно, одно вызывается до рендеринга шаблона (before), а второе - после (after)
В первом можно изменить массив данных, которые передаются в сам шаблон, изменить те, которые есть или добавить свои. НО никак нельзя изменить сам шаблон.
Во втором случае можно изменить output, только это не шаблон, а уже отрендеренный готовый html. Да, его теоретически можно изменить в этом событии, но это еще хуже, чем через ocmod:
1. потому что изменяем мы не шаблон, а готовый html.
Если в шаблоне напр. есть переменная {{ language }} и она одна, то в готовом html будет "Язык" или "Мова" или "Language" для каждого языка свое значение.
Если в шаблоне напр. {{ price }} то в html будет своя цена для каждого товара итд. Если в шаблоне вывод 1 строки в цикле, то в готовом варианте будет 20 строк результата и что изменять каждую?
2. в окмод есть кеш и все изменения сохраняются в кеше и потом берутся из кеша, тут же все делается на лету при каждой загрузке страницы
3. в окмод через кеш можно видеть сам файл, какие там изменения. Тут же мы изменили html код на лету, отдали результат и его движок сразу отдал в браузер, поэтому отладить будет намного сложнее. А когда будет какой-то конфликт, когда один и тот же html код изменит несколько модулей то искать причину будет ой как весело.. А кто-то еще обязательно додумается свой обработчик события закодировать кубом и будет ад в энной степени)))
Насчет "поставить свой" это совсем не вариант, так как если есть несколько модулей которым нужно изменить один html код и кто-то самый умный заменит его на свой то все другие модули просто перестанут работать.
И это по-вашему "не самый плохой вариант"? Да это настоящая жесть еще большая чем сам ocmod. Если в таком виде все будет добавлено в релиз четверки то сразу после этого кто-то сделает модификаторы модулем и всем придется доставлять его как раньше доставляли vqmod и будет хорошо если это будет один модуль а если их вдруг появится несколько или каждый разработчик напишет свой велосипед? То это вообще будет настоящий ад.
И плюс это только работа с шаблонами, а как изменить контроллер через события? Никак.
Как изменить напр. sql запрос в модели если это нужно? Опять никак. Можно или подменить весь код на свой или изменить входные параметры и результат, но сами запросы - никак.
Можно изменить данные при загрузке языков, но только от этого никакого, ведь потом их не вставишь ни в контроллер ни в шаблон через события.
И вот в пользу этого всего сейчас удаляют модификаторы.. -
5 минут назад, RGB сказал:
P.S. Интересно, ждет ли тройку хоть какой-то промежуточный релиз или на ней уже можно ставить крест
Очень навряд ли, если уже работают над 4 версией то какой смысл выпускать новую версию для тройки? Тем более что если ее выпустить то потом все правки придется заново переносить на 4 версию.
-
Спасибо за статью, думаю многим начинающим будет полезной.
Дополню от себя:
1. index, replace, offset, regex я стараюсь вообще не использовать без ситуации, когда без этого вообще никак и даже после этого 2 раза подумаю прежде чем использовать. Иначе потом куча головной боли прежде всего для самого разработчика по поддержке так как чем больше подобных конструкций тем больше вероятность конфликта.
2. изменять шаблоны я бы тоже не стал, особенно в каталоге (ладно админка она то хоть одна, а в каталоге может быть вообще любой шаблон (причем разные его версии) и вообще любым кодом). И что на десятки шаблонов писать разные инструкции? Проще дать пользователю инструкцию: добавить вот эту строчку кода в этот файл шаблона. Многие не согласятся, но это сугубо мое мнение.
3. писать в названии файлов * тоже крайне плохая идея, у меня было немало конфликтов с модулями из-за того, что кто-то в своем модуле добавил какой-то левый код в мой модуль потому что в инструкции было * для всех модулей. Приходилось вручную искать строку, которую ищет этот модуль и добавлять лишние пробелы чтобы не находило и ничего не добавляло в мой файл.
4. не нужно в модификатор писать кучу кода. Если есть какой-то большой кусок кода, который нужно выполнить то намного лучше вынести его в отдельный файл, например модель и через модификатор добавить 2 строчки кода: в первой подключить эту модель и во второй получить результат выполнения метода. Чем добавлять в контроллер 50 строк кода.
5. по возможности избегать использование модификаторов, а там где без этого никак - уменьшать их по максимуму.-
4
-
Сравнение возможностей фреймворков OpenCart и Laravel.
в Блог sv2109
Блог користувача: sv2109
Опубліковано:
З чергами не поки не працював, по артізан писав у пості. А фасади, так, дуже крута та зручна штука, як і весь сервіс контейнер. І до речі, дуже просто все зроблено і будь-який клас можна легко перевести в фасад та через статичний метод запускати методи цього класу з любого місця програми.
от наприклад весь класс фасаду
class Log extends Facade { /** * Get the registered name of the component. * * @return string */ protected static function getFacadeAccessor() { return 'log'; } }і це все!
тобто створюємо класс, який наслідуємо від абстрактного класу Facade, у якому є всього один метод який повертає ім'я зареєстрованого компоненту і все..
Взагалі чим більше працюю з ларавел тим більше дивуюся наскільки тут все зручно для роботи та продумано до дрібниць, видно, що це фреймворк створювався програмістами для програмістів і тут автоматизовано все, що тільки можна автоматизувати, практично всі стандартні задачі для веб.