Aliaksandr
Ну так тем кто не может 2 секции сделать и делает одну может не стоит заниматься такими вещами?
А тем, кто не использует слоты и компоненты, а везде фигачит инклуд, что делать?:)
Pathologic
бухать
Aliaksandr
Давай обсудим где что применять))
Aliaksandr
Литровик мой закончился, теперь можем и обсудить)))
Dmytro
Да где хочешь там и применяй
Dmytro
Притом что хочешь кто ж мешает
Aliaksandr
Да где хочешь там и применяй
Нет уж давай подробнее обсудим, сенсей))
Aliaksandr
В чем разница))
Pathologic
Aliaksandr
Это же м про инклуд можно написать, который везде:)
Aliaksandr
Когда есть и другие варианты
Aliaksandr
Вроде слотов, компонентов и т.п
Dmytro
Если что то все программирование это 1 и 0 в нужной последовательности
Dmytro
Так что все едино;)) только часть говнокод а часть через полгода- год станет говнокодом
Pathologic
а классы нафига нужны, когда можно без них
Aliaksandr
Ну я так понимаю, что и в разработке эво часть блейда считается туфтой, а вторая часть - эталоном?:)
Aliaksandr
Что-то документированное из блейда использовать гуд, а что-то - зашквар:)
Aliaksandr
Но конкретно что именно зависит от фазы луны
Pathologic
так и в пхп часть считается туфтой
Aliaksandr
а классы нафига нужны, когда можно без них
Так это как раз и входит в противоречие, со всеми остальными рассуждениями
Aliaksandr
Концепция ооп - каждый класс делает свой маленький кусок, независимо от окружения. А ты предлагаешь все опять слить в один файл, который определяет все, по типу документпарсера и говоришь что независимые куски - это отстой :)
Aliaksandr
Типа наследуйте главный класс и меняйте там пару методов - и будет вам новый шаблон
Ilya
Ну в блейде жеж там можно подробить все на лярд кусков и подкусков. Или там вышла новая версия где все в одном ? +)
Aliaksandr
Вот и пытаемся выяснить, как правильно дробить, где инклуд, где слот, где компонент
Aliaksandr
Без первомайских лозунгов
Aliaksandr
Почему никто не использует @yield
Ilya
Да там в доках даже нету правил, обычно на простых по дизайну все просто, default.layout. в нем head + include partial header + include partial footer. Внутри head @stack('css') в конце. и также перед /боди @stack('scripts'). В центре @Yield(content). Изи бризи =) Можно даже не инключдить шапку и подвал если лейаут 1. А дальше уже по проекту там есть ли aside повторяющийся и тп, но это уже по идее надо втыкать в yield content
Ilya
Конечно как для модикса хз ... тут удобно что есть route где отдельный view =)
Ilya
Это еще фигня =) Вот когда дойдет до СЕО +)
Aliaksandr
впишешь в лейауте @yield('content') и будешь потом в каждом шаблоне фигачить @section('content') пока не попросят что-то в нем поменять сразу везде
Aliaksandr
а потом на некоторых страницах этот контент должен распадаться на две колонки 3/9, на некоторых других на две колонки 8/4, потом на некоторых в верхней части этой колонки 9/8 должны появиться крошки, а в некоторых эти крошки появляются над колонками в общей col-12
Aliaksandr
и это не выдуманная ситуация, возьми любой платный шаблон - там так и есть
Ilya
Так в модиксе все тож самое , Если есть 15 дизайнерских шаблонов где шапка и подвал одинаковые а центр разный
Aliaksandr
ну так в том и дело, что если мы всунем разметку в сами куски, то придется при необходимости править везде эти куски
Aliaksandr
а если не всунем - то не сможем ничего наследовать
Aliaksandr
и сколько таких "общих" лейаутов будет? и чем это "выгоднее", чем документированный @include? )
Aliaksandr
в общем опять дискуссия ни о чем - общих ответов нет, надо исходить "по ситуации"
Ilya
Это да, уровень дизайна разный может быть, иногда можно свертать так что 1 - 2 условиями сменить положение секций в документе, хз там слева направо и тд =)
Ilya
Еще помогает JS, вы можете реально сократить кол-во partials layouts и тп =)
Aliaksandr
а потом в итоге все разрулят ифами, но не "неправильными ифами [[if]]", а правильными "@if @endif"""
Aliaksandr
потому и говорю что часто это уже вопрос религии или первомайских лозунгов , а не разработки ))
Ilya
Ну из воздуха всеравно ничего не получится, придется или ифы или js или и то и то, или ///
Aliaksandr
Ну из воздуха всеравно ничего не получится, придется или ифы или js или и то и то, или ///
так как раз читая разные агитки "раньше было плохо, сейчас стало хорошо" такое ощущение, что сейчас все само разрулится, без ифов, форичей и всяких там доклистеров :)
Aliaksandr
сначала светлым будущим был DLTemplate, теперь и он уже как стоп-сигнал у зайца мешает развиваться )
Ilya
Я вообще с трудом представляю эту комбинацию =) Понимаю отдельно ларавел, отдельно модикс =)
Ilya
Могу понять админку как в модиксе для ларавел =)
Ilya
Cпуститесь на землю до простых смертных, помогите нубу поставить height для полей richtext в multiTV =) В доках нету не пинайте =) По феншую 2019 =)
Pathologic
так как раз читая разные агитки "раньше было плохо, сейчас стало хорошо" такое ощущение, что сейчас все само разрулится, без ифов, форичей и всяких там доклистеров :)
ну ты просто какие-то ситуации притягиваешь с которыми никто никогда не сталкивался и я так и не понял, чем тебя в таких ситуациях спасут чанки
Pathologic
тебе говорят, что с наследованием быстрее и логичнее все выглядит, а ты отвечаешь типа а чего это вы не хуярите все на инклюдах, раз так можно
Aliaksandr
я не говорю "все на инклудах", я говорю что в реальной жизни достаточно часто сделать на инклудах проще и надежнее, чем на общем шаблоне. Что в принципе и соответствует ооп, за который мы все тут бьемся )
Aliaksandr
ооп это ж не просто функции на классы заменить, это как раз концепция, когда мы каждый отдельный кусок и делаем отдельно и независимо от всех других кусков :)
Aliaksandr
потому и не могу понять рассуждений из разряда "один класс документпарсер это капец как плохо и устарело, но вот один шаблон с наследованиями кусков это замечательно"
Ilya
В блейде обычно все используется, чатсь наследуется, часть инклюдится, зависит от макета
Aliaksandr
да и насчет лишнего в блейде не совсем понятно по сравнению с пхп - там же эта "туфта" как раз не что-то, что осталось из пхп4, а именно новые вещи, которые туда добавлены относительно недавно
Pathologic
шаблон с наследованием кусков это удобно, вот и все
Aliaksandr
шаблон с наследованием кусков это удобно, вот и все
инклуд удобен например тем ,что можно передать доп. параметры
Aliaksandr
вот к примеру у меня есть форма одинаковая, но с разными названиями
Aliaksandr
я в форме делаю {{ $title or "Отправьте заявку"}}
Aliaksandr
а потом в инклуде в разных местах одну и ту же форму с разным title вызываю
Aliaksandr
@include("partials.formwrapper", ['title' => 'Как стать нашим клиентом'])
Aliaksandr
чем плохо )
Ilya
вот к примеру у меня есть форма одинаковая, но с разными названиями
это инклюдом можно решить, например @include('order.form.name', ['title'=>'Супер тайтл'])
Aliaksandr
и вообще вопрос "удобно" очень субъективный
Ilya
Так и надо поидее, принцип повторного использования кода
Dmytro
чем плохо )
Наследование и инклюд не исключают друг друга а дополняют
Aliaksandr
понятно, что делая инклуд я не фигачу каждый шаблон с нуля, а меню только то, что надо менять
Aliaksandr
особенно когда одинаковые куски располагаются в разных местах на разных шаблонах
Aliaksandr
где-то слайдер сверху, где-то снизу, где-то в центре, где-то с другим заголовков - это все через инклуд намного проще, чем разруливать единый шаблон
Ilya
В этом одно из супер преимуществ блейда, условный "чанк" в виде той же формы, можно заинклюдить где угодно =) и ты сам решишь какие данный этот "чанк" будет принимать - я все жду когда в модиксе такое будет - блейд не понадобится =)
Dmytro
Совмещай себе: - наследование - инклюд - секции И будет тебе счастье Тут вопрос в том что в модх парсере по факту только инклюд а секций и наследования нет
Ilya
За-то в модиксе какждый ресурс может быть контроллером =) А в ларке хрена там =) Сделал табличку товаров и пиши контроллер =)
Ilya
А как писать я ща попробую