Bootstrap в OpenCart 2.0

[freelancer]

кто-нибудь может объяснить мне, человеку далекому от верстки, чем плох Bootstrap ?

[chukcha]

Избыточностью

<div id="content" class="col-sm-12">
<div class="row">
<div class="col-sm-8">

И это не самое худшее

 

Наличие сетки - это хорошо

Наличие framework - это хорошо

 

Но за счет наследований 

class="col-sm-12 col-sm-8 col-sm-4 col-sm-2"

 

правка верстки может стать чистым кошмаром

А тем более если еще понадобится dom - формирователи

[JohnnyVega]

Добавлю:

• траблы с переходом на бутстрап след версии (через 1-2 года)
• периодически меняются классы/сетка

 

Избыточностью

Адаптивность, сэр :-)

 

 

кто-нибудь может объяснить мне, человеку далекому от верстки, чем плох Bootstrap ?

Он не плох. Он как и любой инструмент имеет свою сферу применения, свои плюсы и минусы.

[markimax]

кто-нибудь может объяснить мне, человеку далекому от верстки, чем плох Bootstrap ?

То что по быстрому на ум пришло:

1. Избыточностью - раз

2. Костылями адаптации - два (все видели в OC 2 как происходит "адаптация" в шаблонах... :ugeek:  (эту адаптацию можно было спокойно сделать без этих костылей)

3. cм. п.1-2 - тормознутость

4. Совершенно не предсказуемая фрагментация тем и шаблонов. (на мой взгляд - самый большой недостаток)

...

...

...

[RGB]

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

 

Вообще когда встречаю ярых критиков bootstrap, у меня возникает такое чувство, что люди в пол глаза посмотрели на его первую версию, разочаровались в ней, и это свое впечатление априори распространили на все будущие версии

[freelancer]

я столкнулся с версией которая в opencart2.0 сейчас

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

[JohnnyVega]

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

Вот это одно из основных преимуществ бутстрапа

[markimax]

...

Знаете меня учили в университете (системы автоматизации самолетов), что чем проще решение, тем меньше процент отказов оборудования, которое может привести к "гибели". Простой принцип бритвы Окама. Bootstrap по этому принципу ну никак не подходит. Фрагментация и избыточность большой минус, по сравнению с плюсом, для криворуких верстальщиков, уж извините. Посмотрите какой цирк будет с темами для 2.0. Уже и сейчас часто встречал цирк для 1.5.* тех тем, которые были сделаны на bootstrap

[RGB]

Знаете меня учили в университете (системы автоматизации самолетов), что чем проще решение, тем меньше процент отказов оборудования, которое может привести к "гибели".

Я помню, что вы любите приводить примеры из своего образования, но самолеты и сайты, на мой взгляд, не лучшая аналогия. Меня тоже учили в университете (системы автоматизации проектирования), что чем проще решение, тем оно надежнее, но это ведь не значит, что нужно бросать программировать на плюсах и всем переходить на асм, или удалять хром и осваивать lynx? :) Везде есть своя специфика, bootstrap разумно использовать, когда его небольшие минусы - несущественны, по сравнению с выигрышем времени в плане проектирования и удобством использования всех его компонентов. Достаточно понимать, что это - инструмент, и его использование зависит от того, кто его использует, вашему "криворукому верстальщику" нет смысла использовать bootstrap или foundation или любой другой подобный фреймворк там, где можно обойтись простыми решениями, типа unsemantic или даже стареньким 960grid.

[markimax]

...

В программировании такой же принцип, поверьте ;)

Особенно в архитектуре ПО, про которую все забывают

Если вы читали внимательно, то самым главным недостатком считаю фрагментацию... ну очень большой минус.Будем конечно смотреть, но по опыту bootstrapa- a в 1.5.* больше проблем c фрагментацией было, чем преимуществ "верстки".

Bootstrap это инструмент, чтобы верстальщики по быстрому могли "бабло" срубить, не заботясь качестве :) Я так понял это задумка Даниэля (проценты), так же как и сама версия 2.0, чисто маркетинговый ход. (как новая версия iPhone :ugeek: )

[RGB]

В программировании такой же принцип, поверьте ;)

Не надо мне рассказывать о принципах программирования, я не гуманитарий. И не следует подменять здравый смысл методологическими принципами - почему вы не пользуетесь lynx'ом, ведь он же проще и надежнее? :)

 

Если вы читали внимательно, то самым главным недостатком считаю фрагментацию... ну очень большой минус.Будем конечно смотреть, но по опыту bootstrapa- a в 1.5.* больше проблем c фрагментацией было, чем преимуществ "верстки".

Чтобы наша дискуссия была содержательной и чтобы не быть голословным, может вы приведете пример этого очень большого минуса bootstrap - фрагментации?

 

Bootstrap это инструмент, чтобы верстальщики по быстрому могли "бабло" срубить, не заботясь качестве 

Таким инструментом, как калькулятор, тоже можно забивать гвозди, если не уметь им пользоваться :)

[markimax]

Не надо мне рассказывать о принципах программирования, я не гуманитарий. И не следует подменять здравый смысл методологическими принципами - почему вы не пользуетесь lynx'ом, ведь он же проще и надежнее? :)

Без обид - это демагогия уже. Давайте про "линуксы, ассемблеры, калькуляторы" не будем, это не из этой "оперы"

Давайте без демагогии. ;)

Давайте не про мелкую "тактику" а про стратегию.

Суть вот в чем, если архитектуру ПО можно сделать проще - то её надо обязательно делать  проще, иначе потеряется стабильность (если вы конечно уважаете конечных пользователей вашей продукции, а не слепили ПО, чтобы по быстрому срубить "бабло").

Не согласны? ;)

 

P.S. Кстати в своем модуле, для OC 2, я решил вопрос "фрагментации" тем, обертками блоков для каждого виджета и автоадаптером тем.

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

[RGB]

Не большая демагогия, чем ваше сравнение самолетов и сайтов :)

И я всеми руками за конкретику, поэтому и прошу конкретный пример фрагментации, в которой повинен bootstrap (ведь тема о том, чем он плох)

PS Lynx - это не линукс, как вы видимо подумали, а древний консольный браузер

[markimax]

Когда я обучался в церковно- приходской сельской школе, нам говорили : "Чем круче бутсрап, тем чаще будут пользоваться шаблонами вьетнамских пионеров" 

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

Если критично подходить к использованию бутстрапа в ОС:

1. цена верстки индивидуального дизайна возрастет как минимум в 1,5 - 2 раза

2. цена правки дизайна возрастут как минимум в 2 раза

3. Шаблоны (кривые и сырые) уже возрасли в 3раза....

4. Модулей, отображаемых на фронтеде и адаптированных сразу под бутстрап- кот наплакал 

Думаю конечный пользователь нас не поймет. О том что нужна альтернатива с.. и без... это однозначно...

И кстати, кто еще пользуется девайсами на которых невозможно просмотреть сайт при ширине в 980px + резинка?

 

Вот согласен и с этим с Pascha

 

Так что OC 2.0 чисто маркетинговый ход Даниеля (как iPhone 5 от 6) :ugeek:

[freelancer]

на вскидку как на бутстрапе вывести простое popup окно?

[RGB]

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

Файловая структура ОС предполагает многообразие отображения блоков, форм и целых страниц. Как итог: мы имеем возможность прописать стиль под какойто определенный объект на сайте- и он у нас прекрасно впишется и отобразиться. Бутстрап же сам по себе предполагает стандартизацию стилей определенных блоков в пределах всего сайта- иначе, километровый код для каждого блока, под всевозможные и невозможные разрешения...

Как решили эту проблему pav- лики? Да очень просто...инклудом одной схемы отображения по всем страницам, например:

страница категорий, поиск использует 1 файл (назовем его category_view.tpl) которая просто интегрирована в практически пустой код шапка+подвал+боковые колонки) , то же самое и последние/хиты/рекомендуемые/...( category_modul.tpl) Спросите для чего? А все для того же чтоб найти обходные пути и не писать все тот же километровый код стилей...  То есть абсолютно меняется структура  дерева самого движка. Итог:  вкюмод- в топку (ему просто нечего менять там, где нет того что он ищет), многообразие вариантов верстки подменяется однообразием отображения... 

Простой вопрос: есть такие кто добавлял в шапку сайта дополнительную инфу, согласно хотелкам заказчика, а потом верстал чтоб это все корректно отображалось в режиме адаптивности? Уверен, 70% просто скрывали эти блоки))) Так как проще скрыть, чем прописать стили, а потом еще переписать те, что уже есть, чтобы не изуродовать вид сайта... Согласен, бутстрап иногда очень даже привлекателен...но все же наверное не для ОС. Плюс вижу только в том, что конкуренция в верстке и правке будет намного ниже, а значит будут  "рубить бабло" тот кто останется и набъет руку на правке такого рода "улучшений"... ну а про "костыли" которые в многообразии своем появятся в связи с этим...я вообще промолчу)))

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

С изменением структуры я согласен, но опять же - это чья проблема? Фреймворка или движка? :) Очевидно же, что это движки должны подстраиваться под используемые ими фреймворки, а не наоборот, так что это не bootstrap плох, а сама идея перевода опенкарта на него, и то - лишь в глазах тех, кто будет адаптировать старые версии сайтов/модулей под новые, а конечному пользователю вообще все равно, лишь бы работало и смотрелось современнее.

 

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

bootstrap это html/css фреймворк в первую очередь, он не может не предпочитать яваскрипт, или им надо было свой язык в комплекте с фреймворком изобрести, чтобы отказаться от яваскрипта? :)

 

на вскидку как на бутстрапе вывести простое popup окно?

Вот пример из документации с использованием modal.js (по ссылке, которую привел Pascha, все же не офиц. доки, куда имхо стоит смотреть в первую очередь)

<!-- Button trigger modal -->
<button type="button" class="btn btn-primary btn-lg" data-toggle="modal" data-target="#myModal">
  Launch demo modal
</button>

<!-- Modal -->
<div class="modal fade" id="myModal" tabindex="-1" role="dialog" aria-labelledby="myModalLabel" aria-hidden="true">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <button type="button" class="close" data-dismiss="modal" aria-label="Close"><span aria-hidden="true">×</span></button>
        <h4 class="modal-title" id="myModalLabel">Modal title</h4>
      </div>
      <div class="modal-body">
        ...
      </div>
      <div class="modal-footer">
        <button type="button" class="btn btn-default" data-dismiss="modal">Close</button>
        <button type="button" class="btn btn-primary">Save changes</button>
      </div>
    </div>
  </div>
</div>

[markimax]

 

В том то и дело.. как часто пользуются дефолтным шаблоном? И по своему опыту могу сказать, каждый! заказ это новый шаблон, и нередко в каждой! tpl мне приходиться прописывать уникальный класс для блока, дабы реализовать представление дизайнера и заказчика о 

 

только не "лишь бы", а "я хочу чтоб так..." отсюда и появляются "box_latest", "box_featured" и еще куча всяких  "class=" и "id="

Вот здесь я бы сказал так - вот как раз здесь проблема разработчиков модулей.

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

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

Поэтому в принципе здесь как раз проблемы bootstrap-a не вижу. Я вижу проблемы в другом, тактическом плане фрагментаций - к примеру разные верстки и классы табов (как потом привязываться к ним...?), и т.п. привязки, вот с этим у многих будут проблемы и все костыли допилы vqmod выкинете на ... , и перейдете на jquery коды "привязки" (поля Привязка в модулях) как я уже давно сделал. очень универсально, но есть минус, если у пользователя нет квалификации jquery ему будет тяжело, но код jquery для основных "тем-шаблонов" можно сразу прописать в настройках (что и сделал)

[markimax]

Знаете что меня больше всего бесит в opencart... далеко не Bootstrap

Это то что контроллеры не отделены от модели view!

Контроллеры по принципам MVC должны возвращать данные, а не прямо из них выводить готовую страницу (html), это бред и полное не соответствие MVC

Думал в 2.* сделают по принципам MVC - нет так и осталась архитектурная ошибка.

Почему бесит и к чему приводит эта ошибка, обьясню, к примеру я в своем контроллере хочу получить данные о товаре, если бы было сделано по принципам MVC я обратился бы к контроллеру product/product

$product = $this->controller_product_product->index();

 

    public function cont($cont)
    {
        $file  = DIR_APPLICATION . 'controller/' . $cont . '.php';
        $class = 'Controller' . preg_replace('/[^a-zA-Z0-9]/', '', $cont);
        if (file_exists($file)) {
            include_once($file);
            $this->registry->set('controller_' . str_replace('/', '_', $cont), new $class($this->registry));
        } else {
            trigger_error('Error: Could not load controller ' . $cont . '!');
            exit();
        }
    }

 

и получил все данные, которые возвращает стандартный контроллер (плюс все vqmod допилы его). А из контроллера возвращается уже "html" , полный бред, html должна генерировать и выводить модель view, на основе переданных данных от контроллера. И для того чтобы у себя получить данные по продукту мне приходиться заново изобретать "велик", писать свой код и получать данные о товаре (без vqmod допилов понятное дело).
Совершенно не рационально.

[freelancer]

а мне из контролера каталога нужен массив $products со всеми vqmod'ами, а так же из category.tpl, только рендеринг товаров опять же с vqmod'ами, но кто мне их даст?

[markimax]

а мне из контролера каталога нужен массив $products со всеми vqmod'ами, а так же из category.tpl, только рендеринг товаров опять же с vqmod'ами, но кто мне их даст?

Так вот! И я о том же! (прочти внимательно мой пост)

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

View ничего не должно знать о контроллерах.

Согласно принципам MVC так и должно быть, но нет... Даниэль "пошел" другим путем, наплевав на стандарты.

[chukcha]

Не вижу здесь ошибки...

Тогда чем контроллер будет отличаться от модели.

 

Роутер - выбрал контроллер, который на себе и замкнул model и view

конечно, можно было бы отдать роутеру и вывод, но

 

А если вам нужны другие размеры изображений, или еще что-то

 

Поэтому и пишите свой метод  в контроллере

[chukcha]

View ничего не должно знать о контроллерах.

 

Ну... они дети одного класса

 

Но кажется, что в 2.х уже нет прямого доступа к модели (или это мне показалось) из view

[freelancer]

markimax, да
странно, что view рендерить как раз таки умеет

$template = new Template();
$template->data['foo'] = $bar;
$html = $template->fetch('test.tpl');

[markimax]

Не вижу здесь ошибки...

Тогда чем контроллер будет отличаться от модели.

 

Модель - это обмен данными с БД

Контроллер - это логика

За ресайз правильно логика и отвечает. Вам надо другой размер - измените полученный массив данных пришедший от контроллера (перересайзите под себя (в массиве то есть данные об изображениях)) и отправьте на модуль View для рендеринга

Руслан нельзя в контроллер пихать модель View. Получается  не MVC а M.C

[chukcha]

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

 

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

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