Bootstrap в OpenCart 2.0

[markimax]

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

 

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

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

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

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

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

 

[markimax]

Вики:

 

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

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

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

 

 

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

[markimax]

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

[AlexFisher]

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

[markimax]

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

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

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

[chukcha]

Потому что!!!

http://labs.septeni-technology.jp/ruby-tutorial-box/blogging-rails-02-mvc-in-rails/

[markimax]

Потому что!!!

http://labs.septeni-technology.jp/ruby-tutorial-box/blogging-rails-02-mvc-in-rails/

 

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

[chukcha]

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

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

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

[markimax]

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

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

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

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

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

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

[chukcha]

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

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

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

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

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

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

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

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

[markimax]

Повторю... контроллер готовит данные для 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: 

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

[chukcha]

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


 

 

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

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

 

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

 

render()

 

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

[markimax]

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

 

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

 

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

 

render()

 

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

 

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

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

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

[AlexFisher]

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

[markimax]

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

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

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

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

[chukcha]

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

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

 

 

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

 

1. Runtime

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

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

 

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

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

 

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

 

2. WEB

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

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

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

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

 

 

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

 

 

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

[tabook]

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

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

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

 

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

[chukcha]

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

 

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

 

 

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

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

[RGB]

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

[ocdev_pro]

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

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

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

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

Змінено 20 червня 2016 користувачем Waha

[Scorp]

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

 

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

 

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

 

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

 

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

[RGB]

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

[Scorp]

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

[RGB]

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

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

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

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

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

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

[Miha7685776]

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

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

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

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

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

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

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

 

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

Змінено 8 липня 2017 користувачем Miha7685776