Комментарии 42
вменяемая реализация MVC
Потрудились бы раскрыть сие утверждение, ибо у читателей может возникнуть ощущение вто автор не до конца понимает что значат эти три буквы.
Собственно дальше читать особо и смысла не вижу…
+7
Полагаю, что читатели всё же имеют представление о том, что такое MVC, а если впервые встречают эту аббревиатуру — найти на хабре либо в сети не составит труда.
Если же неочевидно, что я имел в виду под этим утверждением, поясню. Во-первых, MVC в движке вообще в принципе есть, что уже немаловажно в сравнении с другими решениями. Во-вторых, она выполнена так, как это привычно видеть любому, кто работал с популярными фреймворками, что включает в себя разные аспекты: и банально структуру директорий, и логику именования и функций контроллера, логику передачи переменных… Ну и так далее. Т.е., открываешь код и пишешь, как обычно. Единственное замечание — это модель, об этом написал в первом «минусе».
Если же неочевидно, что я имел в виду под этим утверждением, поясню. Во-первых, MVC в движке вообще в принципе есть, что уже немаловажно в сравнении с другими решениями. Во-вторых, она выполнена так, как это привычно видеть любому, кто работал с популярными фреймворками, что включает в себя разные аспекты: и банально структуру директорий, и логику именования и функций контроллера, логику передачи переменных… Ну и так далее. Т.е., открываешь код и пишешь, как обычно. Единственное замечание — это модель, об этом написал в первом «минусе».
-4
MVC есть во всех перечисленных вами движках.
И это тоже.
При этом у вас в папке с отображениями может лежать несколько шаблонов дизайна с возможностью выбора нужного в админке.
И это тоже.
0
Спасибо за уточнение, буду знать. Значит, на рынке движков магазинов дела обстоят всё же лучше, чем среди движков «для всего». Вместе с тем не раз сталкивался с товарищами, которые пытались делать магазин (довольно сложный причём) на Joomla...)
0
Но тут уже дело не в Sylius а в Symfony2, автору достаточно понять как все организовано во фреймворке, система бандлов и т.д… Ну проблема ещё в том что Sylius в продакшн не годиться.
0
Спасибо! Люблю Symfony2, делал на нём проект. Правда, преальфа-версия как-то не внушает доверия )
-1
Для вордпресса есть типа что-то того: wpmvc.org/
Но увольте, его нету в вордпрессе. Конечно можно представить шаблоны за вид, что-то ещё за модели, но… нет
Но увольте, его нету в вордпрессе. Конечно можно представить шаблоны за вид, что-то ещё за модели, но… нет
0
Кроме Wordpress (в котором тоже можно спокойно разделять логику и представление) во всех перечисленных CMS/CMF все это есть. Намного интереснее что именно в реализации опенкарта кажется вам принципиально лучше. В той же Joomla можно уже довольно давно писать качественный и гибкий код, но никто этого не делает (во всяком случае я не видел).
+1
Я думаю автору понравилось, что в opencart контроллеры, модели и вью явно разделены (не нужно додумывать и разделять). Там даже папки controller, model, view. А в вордпрессе большинство пишет в шаблонах запросы, и все остальное пихают в functions. Но да, там можно все это разделить.
0
… обязательное поле «модель» при создании товара. Ну нет у человека модели...
Я не понял, вы людьми торгуете?
+3
Нет конечно) но среди товаров моего клиента не было понятия «модель». Был производитель, размеры, были какие-то ещё параметры, но не модель. Думаю, примеров может быть много — одежда, принадлежности для спора, канцтовары, трава для сада… Понятие «модель» в большей степени применимо к разного рода технике.
0
3. Из коробки есть ЧПУ (даже для вордпресса для этого нужно ставить расширение).
Вы ошибаетесь. В WP ЧПУ включается в админке одним кликом. Для транслита — да, нужен плагин.
В чистом Open Cart нужно сделать на 2 клика мышкой больше, а потом для каждого товара прописать slug. «Из коробки» он не умеет сам генерировать ЧПУ из имеющихся названий страниц или товаров.
+1
Да, я имею в виду транслит. Всё-таки, как не крути, а чаще всего нужен он. Помню, пару лет назад возникла такая необходимость, и я провозился довольно долго, пришлось вроде бы даже вручную грохать в базе все slug'и и генерировать заново при помощи плагина (сам плагин тоже пришлось допиливать).
Насчёт прописывания slug'ов — тут Вы правы, спасибо за уточнение, хотя нашёл, что есть, опять-таки, модуль для этих целей.
Насчёт прописывания slug'ов — тут Вы правы, спасибо за уточнение, хотя нашёл, что есть, опять-таки, модуль для этих целей.
-1
>Как следствие, не нужны даже сообщества — движок фактически является фреймворком в классических традициях с примерами для самого себя.
Ну так в основе и есть фреймворк. CodeIgniter называется ;)
>Из коробки есть ЧПУ (даже для вордпресса для этого нужно ставить расширение).
Выше уже сказали, что вы ошибаетесь.
>Да, всё это есть из коробки или в модулях
С последними — аккуратнее. Иногда такие перлы попадаются… Например, ОЧЕНЬ не рекомендую использовать модуль seo_url.
Ну так в основе и есть фреймворк. CodeIgniter называется ;)
>Из коробки есть ЧПУ (даже для вордпресса для этого нужно ставить расширение).
Выше уже сказали, что вы ошибаетесь.
>Да, всё это есть из коробки или в модулях
С последними — аккуратнее. Иногда такие перлы попадаются… Например, ОЧЕНЬ не рекомендую использовать модуль seo_url.
+1
Спасибо за комментарий, внёс Ваш и другие замечания в апдейт )
-1
Вот так вот не проверив, вносите изменения в статью…
0
А что указано не так? Что надо было проверить?)
0
3. В основе движка лежит фреймворк Codeigniter
Вот это, например. В комментариях кто-то сказал и это уже добавлено в статью.
0
Уберите из поста упоминание CodeIgniter, я случайно ввел вас в заблуждение (.
+1
Не знаю, изменилось ли что с тех пор, как приходилось ковыряться в коде OpenCart, но помню, что в легкий шок повергло тогда громадное количество чистого копипаста — вместо того, чтоб повторяющийся функционал вынести в отдельную общую функцию, куски кода во многих местах тупо копировались
+1
OpenCart при должной доработке отличный движок, но имеет кучу детских болезней:
1. Реализация MVC хоть и очень проста, но огромное количество бесполезного кода удручает, например загрузка языковых строк в контроллер и вывод в шаблон.
2. ЧПУ дефектное изначально — создает дубли страниц, разные урлы к товару с главной, и каталога и т.п.
3. Немного туповатые шаблоны — если по верстке надо поменять местами сайдбары, надо прошерстить кучу файлов.
4. Примитивная работа с БД, длиннющие запросы в одну строку.
5. Отсутствие нормальной модульности: надо править ядро, а vqmod сложно отлаживать и разрабатывать.
Конечно, у таких фанатов OpenCart, как я, имеются готовые решения, но авторы бы могли больше внимания уделить архитектуре.
1. Реализация MVC хоть и очень проста, но огромное количество бесполезного кода удручает, например загрузка языковых строк в контроллер и вывод в шаблон.
2. ЧПУ дефектное изначально — создает дубли страниц, разные урлы к товару с главной, и каталога и т.п.
3. Немного туповатые шаблоны — если по верстке надо поменять местами сайдбары, надо прошерстить кучу файлов.
4. Примитивная работа с БД, длиннющие запросы в одну строку.
5. Отсутствие нормальной модульности: надо править ядро, а vqmod сложно отлаживать и разрабатывать.
Конечно, у таких фанатов OpenCart, как я, имеются готовые решения, но авторы бы могли больше внимания уделить архитектуре.
+5
Автор еще забыл упомянуть, что часть модулей загружается в виде файлов для замены, т.к. vQmod не стал стандартом де-факто. Поэтому после покупки модуля может понадобиться его портировать под vQmod — diff и много веселья.
0
Простите за некропостинг, но что за "готовые решения"? Я повелся на утверждение что OC MVC и теперь в проекте очень мучаюсь с контроллерами на сотни строк в едином методе на 50% состоящими из чистых запросов (которым раз уж нет ActiveRecord место в модели).
Есть какие-то способы его отправить на фитнес (игра слов на тему DRY)?
Тот же vqmod был бы терпимым, и заменяемым руками на наследование, если бы были бы хоть какие-то зачатки SOLID. Ведь переопределив маленькое поведение в классе на десяток строк я не могу просто отнаследоваться от родного класса (контроллера конечно же, толстого!) заменив один метод и прописав нужный класс в регистр — там весь класс и есть один метод.
Вот реально я не знаю что с этим делать.
По моему мнению тут только переписывать весь движок с нуля, только подглядывая в исходный код.
Но функционала много да. И если из коробки и не допиливая, а только доставляя модули, то хороший шоп.
Не сарказма ради, просто интересуюсь, как можно себе жизнь облегчить. Просто проект из-за того что я дурак не проверил а поверил словам "полноценный MVC" влез в это болото. То что во фреймворках делается за час тут делается неделями.
Есть какие-то способы его отправить на фитнес (игра слов на тему DRY)?
Тот же vqmod был бы терпимым, и заменяемым руками на наследование, если бы были бы хоть какие-то зачатки SOLID. Ведь переопределив маленькое поведение в классе на десяток строк я не могу просто отнаследоваться от родного класса (контроллера конечно же, толстого!) заменив один метод и прописав нужный класс в регистр — там весь класс и есть один метод.
Вот реально я не знаю что с этим делать.
По моему мнению тут только переписывать весь движок с нуля, только подглядывая в исходный код.
Но функционала много да. И если из коробки и не допиливая, а только доставляя модули, то хороший шоп.
Не сарказма ради, просто интересуюсь, как можно себе жизнь облегчить. Просто проект из-за того что я дурак не проверил а поверил словам "полноценный MVC" влез в это болото. То что во фреймворках делается за час тут делается неделями.
+1
Интересно конечно сравнивать движок заточенный под интернет-магазин (OpenCart) и движок под блог (Wordpress, ну ладно — еще и посложней сайты неслжно сделать), про Joomla и Drupal сказать немогу, но ИМХО это более универсальные комбайны, но точно не интернет-магазины. И ссылаться на Wordpress говоря что в OpenCart есть такая фишка (которая для магазина ну очень логична), и в этом OpenCart крут, как то бессмысленно.
Максимум на что можно расчитывать от Wordpress это магазин-витрина, для большего — вперед шерстить движки интернет-магазинов.
Почему не идет сравнение с другими движкаими интернет-магазинов? Хотябы поверхностный обзор других двжиков, уже было бы поадекватней сравнение
Максимум на что можно расчитывать от Wordpress это магазин-витрина, для большего — вперед шерстить движки интернет-магазинов.
Почему не идет сравнение с другими движкаими интернет-магазинов? Хотябы поверхностный обзор других двжиков, уже было бы поадекватней сравнение
+3
Дело в том, что многие на полном серьёзе делают относительно крупные магазины на джумлах и вордпрессах, и у людей действительно стоит вопрос — выбрать вордпресс или опенкарт для магазина. Одна из целей поста — развеять сомнения и обратить внимание в сторону узкого и качественного решения. А в будущем мне, конечно, хотелось бы ещё сделать пару проектов на других (узкоспециализированных) движках магазинов и сделать сравнительный обзор уже их.
-1
Тогда стоило бы дать в статье конструктивную информацию почему НЕ стоит делать магазин на Wordpress, или почему стоит выбирать для магазина движок заточенный под магазин (хотябы на примере OpenCart). У вас в статье на это даже намека нет.
А вот что касаеться вопроса выбора — то по хорошему это должен объяснить разработчик, что лучше в конкретном случае.
А вот что касаеться вопроса выбора — то по хорошему это должен объяснить разработчик, что лучше в конкретном случае.
0
У меня знакомой нужно было ИМ. Ей очень понравился шаблон под WooCommerce. Я ей поставил WP+WooCommerce. Купили шаблон. Всё настроили. Магазин работает отлично, её полностью удовлетворяет, товары очень хорошо продаются.
Думаю, что в инструменте важно, чтобы он работал и выполнял свою функцию, обеспечивая безопасность, удобство и ряд других параметров.
P.S. Кросс-селл и ап-селл в WooCommerce делаются в один клик — в опенкарте нужны костыли.
Думаю, что в инструменте важно, чтобы он работал и выполнял свою функцию, обеспечивая безопасность, удобство и ряд других параметров.
P.S. Кросс-селл и ап-селл в WooCommerce делаются в один клик — в опенкарте нужны костыли.
0
OC имеет крайне низкий уровень вхождения и может быть полезен новичку, который взялся работать с ним понять, как делать не надо. В движке много архитектурных проблем. К тому же, он не развивается вместе с языком: совсем недавно в дистрибутиве был драйвер mysqli, который банально не работал, т.к. там не было нужного кода. То есть, в 2013 году движок не умел mysqli. Кажется, позже допилили, но мне проверять не пришлось — уже ушел от работы с ним.
А еще в нем много лишнего: вышеупомянутые копипасты, бесполезная работа с передачей строк локали в шаблон, занимающая, порой, больше места, чем логика.
Некоторые довольно востребованные вещи в нем можно сделать только костылями, если нужно оформить это модулем, который встанет на магазин, а не переписать движок.
Хотя чтобы быстро склепать простенький магазин — взять можно.
А еще в нем много лишнего: вышеупомянутые копипасты, бесполезная работа с передачей строк локали в шаблон, занимающая, порой, больше места, чем логика.
Некоторые довольно востребованные вещи в нем можно сделать только костылями, если нужно оформить это модулем, который встанет на магазин, а не переписать движок.
Хотя чтобы быстро склепать простенький магазин — взять можно.
0
Я тоже сделал несколько магазинов на опен-карте и остался вполне им доволен. Все минусы что автор привел и вправду есть с ними сталкиваешься сразу же — и это сильно достает. Но реалность такова что он отлично справляется и с яваскрипт запросами и с MVC архитектурой. Я когда работал на фирме делал магазины исключительно на опен-карте а обычные сайты на друпале — несколько дней — проект готов. Самое классное — это что цену товаров можно указывать в баксах и выбирать валюту на сайте устанавливать свой курс. Вот сейчас у нас гривна взлетела на 50% все звездец — представте магазины где база данных из 10тыс товаров и все приходится вручную пересчитывать а доллар прыгает каждый день. Ставим курс на сайте цены изначально в долларах и все.
Еще очень понравилось что можно смело передавать данные постом прямо в поиск. Дописал готовый движок по поиску шин аккумуляторов и дворников на пхп — сделал страничку поиска на штмл, так как аяксом внедрить показ товаров из своего модуля прямо в каталог — то есть вывод товаров по нужным мне критериям я не смог, хотя ребята написали и продают готовые решения по 500баксов. В общем вывод критерий по поиску их HTML в движок опенкарта. И вот тебе вывод нужных товаров по любому запросу из описания товара, даже кастомить поиск и алгоритм его можно. В общем классная штука. Заказы и рассылки писем и много разных плюшек — просто зверь а не движок.
Еще очень понравилось что можно смело передавать данные постом прямо в поиск. Дописал готовый движок по поиску шин аккумуляторов и дворников на пхп — сделал страничку поиска на штмл, так как аяксом внедрить показ товаров из своего модуля прямо в каталог — то есть вывод товаров по нужным мне критериям я не смог, хотя ребята написали и продают готовые решения по 500баксов. В общем вывод критерий по поиску их HTML в движок опенкарта. И вот тебе вывод нужных товаров по любому запросу из описания товара, даже кастомить поиск и алгоритм его можно. В общем классная штука. Заказы и рассылки писем и много разных плюшек — просто зверь а не движок.
0
Да но когда я сталкивался с переводом валюты (автоматически, не выставляя значения), то данные брались из какой-то ссылки, которая была захардкодена где-то в недрах. Ссылка шла на какой-то источник из штатов.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько слов о движке интернет-магазинов OpenCart