Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

Bootstrap в OpenCart 2.0


freelancer
 Поделиться

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

Контроллер может и рендерить, а отдать json, например.

 

Не вижу противроечий

И теория не отрицает вырожденных случаев.

Так вот не должен он (контроллер) рендерить. Это уже не MVC

Он должен вернуть массив данных (который, к примеру, Руслан или я,  хочет заюзать под себя со всеми высчитанными vqmod допилами), а вот модель View (final class, которого нет в opencart) должна рендерить те данные которые пришли ей.

Прочитайте мой пост "почему"

 

MVC-Process.png

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

Вики:

 

В оригинальной концепции была описана сама идея и роль каждого из элементов: модели, представления и контроллера. Но связи между ними были описаны без конкретизации. Кроме того, различали две основные модификации:

  1. Пассивная модель — модель не имеет никаких способов воздействовать на представление или контроллер, и используется ими в качестве источника данных для отображения. Все изменения модели отслеживаются контроллером и он же отвечает за перерисовку представления, если это необходимо. Такая модель чаще используется в структурном программировании, так как в этом случае модель представляет просто структуру данных, без методов их обрабатывающих.
  2. Активная модель — модель оповещает представление о том, что в ней произошли изменения, а представления, которые заинтересованы в оповещении, подписываются на эти сообщения. Это позволяет сохранить независимость модели как от контроллера, так и от представления.

Классической реализацией концепции MVC принято считать версию именно с активной моделью.

 

 

В opencart - пассивная реализация, читаем нативная. А я бы сказал - "ленивая", из-за чего разработчики страдают

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

И всё хорошо в opencart, мне нравиться его архитектура (получше, проще, безопаснее  чем wp и drupal имхо) , но только до вывода View. Вот еще бы его добавить отдельно от контроллера и было бы очень гибко. Поэтому отсутствие View меня больше бесит чем присутствие bootstrap (уже полностью равнодушен, что он есть, что его нету, а вот без V - приходиться изобретать "велики"). Тогда и за layouts отвечал бы роутер seo_url (до сих пор не пойму почему layouts вычисляются в "блоках", а не в роутере, получается избыточные вычисления и лишняя нагрузка) и т п

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

Марк, классная картинка. Устаканивает в голове то, что пытаешься кому-то объяснить, когда имеешь в виду мвц 

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

Марк, классная картинка. Устаканивает в голове то, что пытаешься кому-то объяснить, когда имеешь в виду мвц 

Странно почему её Даниэль не видел :-D

Картинка то из викки

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

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

 

Те же я...ца только в профиль. View отделено от контроллера

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

Да-да жареные и вареные

Заметьте, на моем рисунке - view имеет связь между контроллером

С роутером имеет связь только контроллер.

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

Да-да жареные и вареные

Заметьте, на моем рисунке - view имеет связь между контроллером

С роутером имеет связь только контроллер.

Не вопрос я писал об этом, связь может быть, но... самое главное (на вашей картинке) View отделено от контроллера!

В opencart - роутер - это "seo_url", а вот view нету вообще, прямо в контроллере идет "вывод" html, котнтроллер по принципам MVC  должен возвратить  массив данных и передать на View, который уже должен (отдельным final class) отрендерить и вывести View

"Ваша" картинка полностью соотвествует MVC в отличие от opencart (там нативно скорее MC+v)

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

Погодите, контроллер готовит массив данных для View, не так ли?

view - хотя у него и есть команды вывода - только формирует html

Да, контроллер занимается рендерингом, а вернее только дает команду

Вывод происходит в index файле (роутере) $response->output();

Потому что ни seo_url, ни seo_pro, ни кто-либо другой из сеореарйтеров не являются роутерами (они только надстройки)

роутером является $_GET['route']

Повторю... контроллер готовит данные для view

кроме того, ведь контролер работает не с одним шаблоном (header, footer, left, right etc)

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

Повторю... контроллер готовит данные для view

кроме того, ведь контролер работает не с одним шаблоном (header, footer, left, right etc)

Что в opencart возвращает контроллер? ;) отрендеренный "html"

А по принципам MVC - он должен возвратить массив данных. (который разработчик мог бы изменить или использовать в своих контроллерах)

А вот "роутер" бы мог уже потом рендерить

Вот так приблизительно:

$view->render();

$response->output();

 

Т.е. отделить контроллер от view

 

А сейчас прямо в контроллере - идет мешанина

 

К примеру module/banner.php

   ...     
if (file_exists(DIR_TEMPLATE . $this->config->get('config_template') . '/template/module/banner.tpl')) {
            return $this->load->view($this->config->get('config_template') . '/template/module/banner.tpl', $data);
        } else {
            return $this->load->view('default/template/module/banner.tpl', $data);
        }

:ugeek: 

Совершенно, не так как на "вашей" картинке :)

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

ага, а эти данные будут выданы (заменены) в top,left,right,bottom и помещены в в исходящий...


 

 

А по принципам MVC - он должен возвратить массив данных.

$data - массив данных для шаблона

 

$this->load->view($this->config->get('config_template') . '/template.tpl', $data);

 

render()

 

т.е. вы считает что рендерить должен роутер?

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

ага, а эти данные будут выданы (заменены) в top,left,right,bottom и помещены в в исходящий...

 

$data - массив данных для шаблона

 

$this->load->view($this->config->get('config_template') . '/template.tpl', $data);

 

render()

 

т.е. вы считает что рендерить должен роутер?

 

Нет, я написал "приблизительно" :-D

По архитектуре MVC отдельно.

Мало того, по классической архитектуре View должен отдавать "сообщения" контроллерам, что блок отрендерин (т.е. изменения, например вдруг другой контроллер запросит перерендерить согласно шаблонов пользователя этот блок и т п )

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

Странно, что эти два человека еще не срутся и не поливают друг-друга тем, чем положено в таких случаях поливать =)

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

Странно, что эти два человека еще не срутся и не поливают друг-друга тем, чем положено в таких случаях поливать =)

А зачем нам, разработчикам "сраться" вообще :-D

Тем более если у обоих доводы подтверждают их виденье на проблему.

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

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

Странно, что эти два человека еще не срутся и не поливают друг-друга тем, чем положено в таких случаях поливать =)

Не вижу причин :)

 

 

Вернемся к нашим баранам

 

1. Runtime

В runtime приложениях View, может быть активным,

а контроллер и модель (условно) - слушатели событий поступающих от view (десктопные приложения тому пример)

 

Model должна быть универсальной по своей сути

на вход должны поступить данные фильтрации - и вернуть она должна данные из нужного источника.

 

Контроллер - это логика обслуживания View

 

2. WEB

В конечном итоге view выступает браузер

Conroller - как слушатель в соответствии с командой роутера выбирает данные и отдает контент

Выбирает данные - это вызов методов model'и  (см п1. model - универсальна, что попросили, то и отдала)

А отдает - рендеринг шаблона (который по сути есть отражение клиентского view)

 

 

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

 

 

pps свою первую cms (здесь улыбка) построил на активном шаблоне, выбором шаблона занимался роутер и render, который собирал патерны из представления и отдавал контроллеру. Эта система живет себе уже с 2008, но тогда об MVC только начинали говорить

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

Не соглашусь про начинали говорить в 2008. Мы в 2006 начали писать огромный продукт с промышленной эксплуатацией на тысячи рабочих станций как раз таки используя теперь уже классический MVC :)

Правда благополучно похоронили в 2010, но явно не из-за MVC ))))

Или речь про Web-разработку?

 

Кстати, чтобы было хоть чуть-чуть в тему: Bootstrap пока что мне нравится, попробовал в своем крайнем творении, выглядит на удивление довольно сносно.

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

Ок... я в веб пришел из embedded systems и oracle-dba (поэтому и дата поздняя и (вспомните) тогда массово стали появляться различные framework'и)

 

MVC - это всего лишь объектный патерн проектирования.

 

 

Или речь про Web-разработку?

web-разработка

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

  • 5 месяцев спустя...

Тем временем вышла альфа 4-го bootstrap и внезапно появился магазин официальных тем, вот интересно, будут ли 2-й опенкарт пересаживать на новую версию, хотя по верстке там вроде изменений не так уж много

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

  • 9 месяцев спустя...

Достаточно долго работаю с Bootstrap.. начиная с первых версий. Бутстрап это такая дрянь которая поможет программисту который плохо знает верстку сделать что-то похожее на сайт...
Плюсов в его использовании для меня нет...
Загроможден, не гибкий, сложную верстку под не шаблонный дизайн сделать трудно и долго..

Адаптивность слишком уж преувеличеное преимущество... своими руками сделаю быстрее, качественней и понятней для любого фронтендщика.

Bootsrap хорош для шаблонных проектов с кучей костылей...

Кому нравиться пускай, "на вкус и цвет...."

Изменено пользователем Waha
Ссылка на комментарий
Поделиться на других сайтах

  • 1 год спустя...

Крайне интересная тема.

 

Получается что использование бутстрапа - вред, несмотря на то что все шаблоны делаются на нем и все исключения караются недовольством.

 

Так дело обстоит как я понимаю не только с бутстрапом? UiKit, Foundation, Semantic Ui тоже попадают под раздачу?

 

И как тогда поступить? Писать шаблон на чистом CSS или с использование Sass? А как же тогда соблюдению структуры верстки? OcMod и т.д?

 

Какой выход из всего этого если решил писать шаблон?

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


Если делается шаблон для собственных нужд под свой магазин например, то хоть на каком-нибудь 960 grid делайте, а вот если шаблон делается на продажу для массового пользователя, то я не думаю, что стоит изобретать велосипеды в ущерб совместимости, если так не нравится стандартный или около-стандартный вид bootstrap, его (при желании и наличии массы времени) можно изменить до полной неузнаваемости - главное не забывать, что авторы модулей ничего не знают о вашем шаблоне и справедливо полагают, что вы следуете стандартам фреймворка.

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

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

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


23 часа назад, Scorp сказал:

кривую трудномасштабируемую архитектуру

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

23 часа назад, Scorp сказал:

и добавить им головной боли если они решат двигаться дальше в развитии...

А куда им двигаться и о какой головной боли речь? Если даже они хотят как-то переделать шаблон, используемый фреймворк им абсолютно никак не помешает, даже более того - популярность bootstrap позволяет легко найти массу готовых решений и реализаций, которые значительно облегчат развитие исходного шаблона, если потребуется туда что-то добавить.

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

В 07.07.2017 в 14:33, Scorp сказал:

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

именно так! после появления флексов, флоаты стали не популярны, тем более хороший фронтендер делает с бэм. 

поэтому бут не попадает в правила скажем так. 

создал к примеру с бэм, а расширения сделаны с учетом бута. ну пилить тому кто делает шаб, а после придется пилить хозяину.

рынок разделен. на бэм (как сейчас модно) и на другие. бэм делают на крупных проектах (там он требование) а в случаи ширпотреб и фриланс скажем так, верстают как попала).

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

 

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

Изменено пользователем Miha7685776
Ссылка на комментарий
Поделиться на других сайтах


Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Поделиться

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...

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

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