Использование кратких php тегов, в том числе для вывода, запрещено правилами WordPress (для плагинов как мининимум)
"Лучшим будет собрать необходимое в контроллере" Не спорю, шаблонизаторы хорошая вещь, сам использую twig если делаю тему с нуля. Но если пройти по 5 проблемам что я обозначил, это будет ответом только на №4 (Спагетти код). Остальные проблемы остаются. Плагин же решает все указанные проблемы
"Это дополнительная проблема, а не решение." Если вы так считаете, то не плохо бы было аргументировать.
Альтернативные решения всегда есть. Вопрос в том что они корпорациями даже не рассматриваются, т.к. они всегда в поиске максимальной прибыли, и пока рынок молча делает что надо это не изменится. Что по сути дает корпорация - продукты. И взамен мы делимся данными и смотрим их рекламу. Так почему не предоставить опцию платной подписки? Хотя бы в рамках Google, чтобы можно было заплатить за использование их сервисов, в одном месте, и не видеть рекламу, не передавать свои данные? Если хотя бы FAANG каждый сделает такое на своей стороне и будет общий сервис где все это можно будет оплатить пакетом, разве другие компании не подключаться к такому? И открыть код, чтобы была гарантия a) что правила не будут изменены в одностороннем порядке б) что игра идет по правилам, и если пользователь платит то данные никуда не идут в) в случае каких-либо проблем пользователи не останутся у разбитого корыта. Конечно будут вопросы интеллектуальной собственности и т.д. Я имею ввиду вектор движения, не буквальность. В конце концов корпорации и должны предлагать различные решения, а не пользователь на хабре придумывать что делать
И кроме того текущая модель подается как безальтернативная модель. Я имею ввиду нельзя платить условные 10$ и получать контент без рекламы везде. Да, такое есть на отдельных сервисах, но этих сервисов тысячи. Даже нет такой подписки в рамках одной корпорации.
И, вроде как вообще не проблема иметь альтернативу большинству существующих сервисов - мессенджеры, почта, банки, такси, что угодно.
Вот тут вся суть и кроется. Проблема в том что мы используем не очередной калькулятор Google, а технологии которые стали базовыми для многих других.
Если в один прекрасный день все продукты того же Google перестанут быть доступны для большинства (по различным причинам, хакерская атака с удалением всего и вся, смена руководства и назначения непомерной платы за использование продуктов и т.д. на вашу фантазию) то вы можете оценить урон который будет нанесен? Сам Android без проприетарных частей не имеет смысла (уведомления, магазин приложений, gsf, google pay и т.д ), разработчики не смогут даже выпустить обновления для своих приложений, чтобы убрать ту же GSF зависимость или перевести уведомления на свои сервера. Не будет браузера, поисковой системы, почты, meetings, Google Cloud, Google analytics и с десяток других продуктов. Сколько лет понадобится чтобы восстановить сервисы и сайты которые были завязаны на Google Cloud? А их nameservers. Каких усилий и вложений это будет стоит, и сколько времени займет? Большинство людей использует только один браузер, внезапно они не смогут даже скачать замену или прочитать новости на эту тему..
Конечно я нарисовал сюрреалистический сценарий, и такого скорее всего не будет. Но я хочу подчеркнуть именно степень зависимости большинства людей и продуктов от продуктов и сервисов корпораций, которые уже давно стали по сути инфраструктурой для рядовых сервисов.
Важнейшие для меня - это те, внезапная потеря которых приведет к финансовым потерям и социальным трудностям для многих людей. Как операционная система, мессенджеры, браузер, поисковик, почта и тому подобное. Например в вебе во многом с этим дело обстоит куда лучше. Все основные части открыты. Тот же LAMP, и прочий минимум необходимых элементов. Также же git, основные CMS и прочее
Хорошая идея. Например GitLab имеет две лицензии : открытую и корпоративную с поддержкой. Про Canonical (Ubuntu, открытая ОС) слышал тоже, зарабатывает на услугах для компаний.
Для гиков всегда есть возможность заморочиться и поставить себе Lineage или, вообще, Sailfish
Так в этом и проблема, что корпорации с каждым годом лишь прибавляют в весе. Google контролирует свой PlayMarket, и все приложения под android концентрируются там. А по сути Lineage использует только альтернативный клиент для PlayMarket (F-Droid не в счет, вы там банковские приложения или другие что используете каждый день не найдете), т. е . все это происходит до тех пор, пока это не мешает гуглу. И с каждым годом порочный круг разорвать будет все труднее. По этому как по мне - то что по силам каждому уже сейчас - осознанно выбирать важнейшие продукты и отдавать предпочтение open source. Это то что я делаю крайнее время, и этой идеей хотел поделиться (я явно не первооткрыватель, просто хотел поднять еще раз тему). И для меня лучше делать что-то, чем совсем ничего)
Мне понятно что и зачем делают большие корпорации и я практически уверен, что тот же гугл просто не успеет "захватить власть над миром" раньше чем перестанет чувствовать новые тренды
Вполне возможно, однако например на пару с кем-то поделить рынок вероятно сможет без проблем. Как сделал это Google Play и AppStore. Или как Visa (57%) и MasterCard (26%, кстати проценты похожи на Chrome и Safari). Intel и AMD, и так далее. Сейчас условный Google получает все без проблем, и ему нет смысла меняться. Если рынок (пользователи) не предпримут никаких шагов, то ситуация так и продолжит развиваться. По этому выбор альтернативных вариантов по мне может изменить ситуацию, если значительная часть пользователей будет выбирать другие продукты, то это будет причина для Google чтобы пересмотреть правила игры, а в идеале, как я убежден, рынок должен устанавливать правила, а не отдельные игроки
Я согласен что идея про цивилизованные способы передачи данных хорошая, однако суть статьи несколько в другом. По моему мнению критически важные для большого количества людей продукты должны быть открыты и таким образом менее зависимы от одной компании. Что очень трудно представить в сегодняшнем мире. По этому идея осознанного выбора продуктов на сегодня мне кажется более перспективной. Вы правы, сегодня гугл зарабатывает рекламой, но кто может сказать, что будет завтра? Я думаю история предоставила достаточно примеров, когда монопольное владение чем-либо в конечном счете заканчивалось огромными проблемами для людей. В конце концов рынок формируют именно пользователи, и они должны устанавливать правила игры, а иначе при монополизме выходит что весь рынок играет по правилам нескольких крупных игроков
Сразу видно как внимательно прочитали статью. Я указал ссылку на утилиту, которая позволяет это сделать в ваш один клик, и указал почему не рекомендую ее использовать. Критикуешь - предлагай. Вместо голословности поделитесь проверенными вариантами и я добавлю их в статью
Каким образом можно переиспользовать блок? Наследоваться и создавать новый класс с новым шаблоном?
Да, абсолютно верно. Создать класс наследник и далее можно расширить стили и/или переопределить шаблон. Пример расширения стилей. Тоже касается и шаблона. Просто создать twig шаблон. Twig также поддерживает расширение, по-этому можно расширить (extend) родительский шаблон и переопределить только его часть
Спасибо за уточнение, не сталкивался с Yii, посмотрел, у них пожалуй самые развитые блоки (виджеты) из подобных, но насколько я понял это не самостоятельное решение, и отличается по функционалу с пакетом, по-этому желающие (например я) не смогут использовать это как альтернативу.
ArticleC и HeaderC это че такое?)))
Это суффиксы, чтобы отметить Controller-ы для автозагрузки, модель Article, а контроллер ArticleC. Использовать 'Controller' целиком как суффикс было бы слишком многословно при большом количестве блоков.
Могли сократить сущности до модель — вьюха, а сам рендеринг скинуть на какую-то отдельную сущность например Renderer, т.к. для каждой модели не нужен отдельный контроллер.
Интересная мысль, изначально разделил чтобы не смешивать данные и зависимости, но если рассматривать в контексте блока (виджета) как целую сущность то это имеет смысл. Подумаю над этим.
Вы же диктуете правила, которые можно обойти интерфейсами
Тогда сама идея изменится. Благодаря ограничениям нет необходимости указывать каждый раз путь к шаблону, нет необходимости указывать класс модели для контроллера. Не вижу ничего плохого в наследовании, тем более что наследники будут решать четко установленные задачи. И использование protected полей класса вместо прямого массива (как например в в symfony) дает ряд преимуществ
Почему в кавычках? — Да потому что в Вашем случае это не модели и не контроллеры.
В привычном прямом понимании да. Данные имена были выбраны чтобы люди знакомые с MVC могли провести аналогии. Если рассматривать каждый блок в отдельности, то Model ожидаемо предоставляет данные, View (twig) их отображает, а Controller управляет зависимостями
С некоторыми шаблонами «конкурентов» знаком, как WordPress, Symfony, Codeigniter. Также альтернатив, подобных уже существующих пакетов, которые делают то же самое при поиске не нашел.
нейминг конечно ужасный :)
Если не трудно, хотелось бы пару примеров из кода с альтернативной версией (правильной по вашему)
Спасибо за ссылки и конструктивный комментарий, по привычке использовал WordPress code style, PSR-12 гораздо уместнее, обновил. Касательно того что
MVC — это не про наследование модели и контроллера от одного класса
абсолютно согласен, однако в данном случае наследование необходимо для чисто технического момента, как чтение полей, и ничего более. И разделение: модель — отображение — контроллер для распределения ответственности по-моему в данном пакете реализовано довольно прозрачно.
Так же попробуйте учесть варианты, что блоки не обязательно должны быть в одном каталоге
А зачем? Пакету необходимо указать лишь одну родительскую директорию, а поддиректорий может быть сколько угодно. Я думаю для большинства случаев этого будет достаточно.
В целом — идея может и взлетит, но сейчас это не похоже на пакет, которым можно пользоваться.
У вас есть конкретные предложения по этому поводу?
На данный момент в своих проектах я группирую по темам, как
Block
block.scss
Theme
First
block--theme--first.scss
Это совпадает с BEM и мне кажется более удобным, чем разделение по типам файлов. Касательно одинаковых имен, да, технически это возможно, но я исходил из удобства редактирования (имхо), в случае одинаковых имен когда в IDE будут открыты одновременно несколько блоков различать их будет менее удобно, и опять же текущий способ более похож на BEM и будет более привычен для тех кто знаком с ним. Копирование блоков я использую довольно часто, в каждом проекте есть дефолтный блок и я создаю блоки с него, чтобы избежать ненужной рутины. По-этому в пакете также есть команда для копирования блоков с заменой имен
Спасибо, поправил
Использование кратких php тегов, в том числе для вывода, запрещено правилами WordPress (для плагинов как мининимум)
"Лучшим будет собрать необходимое в контроллере"
Не спорю, шаблонизаторы хорошая вещь, сам использую twig если делаю тему с нуля. Но если пройти по 5 проблемам что я обозначил, это будет ответом только на №4 (Спагетти код). Остальные проблемы остаются. Плагин же решает все указанные проблемы
"Это дополнительная проблема, а не решение."
Если вы так считаете, то не плохо бы было аргументировать.
Добавил svg для иконки. По поводу остальных - не уверен, в оф. документации такой информации нет
Альтернативные решения всегда есть. Вопрос в том что они корпорациями даже не рассматриваются, т.к. они всегда в поиске максимальной прибыли, и пока рынок молча делает что надо это не изменится.
Что по сути дает корпорация - продукты. И взамен мы делимся данными и смотрим их рекламу. Так почему не предоставить опцию платной подписки? Хотя бы в рамках Google, чтобы можно было заплатить за использование их сервисов, в одном месте, и не видеть рекламу, не передавать свои данные? Если хотя бы FAANG каждый сделает такое на своей стороне и будет общий сервис где все это можно будет оплатить пакетом, разве другие компании не подключаться к такому? И открыть код, чтобы была гарантия a) что правила не будут изменены в одностороннем порядке б) что игра идет по правилам, и если пользователь платит то данные никуда не идут в) в случае каких-либо проблем пользователи не останутся у разбитого корыта.
Конечно будут вопросы интеллектуальной собственности и т.д. Я имею ввиду вектор движения, не буквальность. В конце концов корпорации и должны предлагать различные решения, а не пользователь на хабре придумывать что делать
И кроме того текущая модель подается как безальтернативная модель. Я имею ввиду нельзя платить условные 10$ и получать контент без рекламы везде. Да, такое есть на отдельных сервисах, но этих сервисов тысячи. Даже нет такой подписки в рамках одной корпорации.
Вот тут вся суть и кроется. Проблема в том что мы используем не очередной калькулятор Google, а технологии которые стали базовыми для многих других.
Если в один прекрасный день все продукты того же Google перестанут быть доступны для большинства (по различным причинам, хакерская атака с удалением всего и вся, смена руководства и назначения непомерной платы за использование продуктов и т.д. на вашу фантазию) то вы можете оценить урон который будет нанесен? Сам Android без проприетарных частей не имеет смысла (уведомления, магазин приложений, gsf, google pay и т.д ), разработчики не смогут даже выпустить обновления для своих приложений, чтобы убрать ту же GSF зависимость или перевести уведомления на свои сервера. Не будет браузера, поисковой системы, почты, meetings, Google Cloud, Google analytics и с десяток других продуктов. Сколько лет понадобится чтобы восстановить сервисы и сайты которые были завязаны на Google Cloud? А их nameservers. Каких усилий и вложений это будет стоит, и сколько времени займет? Большинство людей использует только один браузер, внезапно они не смогут даже скачать замену или прочитать новости на эту тему..
Конечно я нарисовал сюрреалистический сценарий, и такого скорее всего не будет. Но я хочу подчеркнуть именно степень зависимости большинства людей и продуктов от продуктов и сервисов корпораций, которые уже давно стали по сути инфраструктурой для рядовых сервисов.
Важнейшие для меня - это те, внезапная потеря которых приведет к финансовым потерям и социальным трудностям для многих людей. Как операционная система, мессенджеры, браузер, поисковик, почта и тому подобное. Например в вебе во многом с этим дело обстоит куда лучше. Все основные части открыты. Тот же LAMP, и прочий минимум необходимых элементов. Также же git, основные CMS и прочее
Хорошая идея. Например GitLab имеет две лицензии : открытую и корпоративную с поддержкой. Про Canonical (Ubuntu, открытая ОС) слышал тоже, зарабатывает на услугах для компаний.
Так в этом и проблема, что корпорации с каждым годом лишь прибавляют в весе. Google контролирует свой PlayMarket, и все приложения под android концентрируются там. А по сути Lineage использует только альтернативный клиент для PlayMarket (F-Droid не в счет, вы там банковские приложения или другие что используете каждый день не найдете), т. е . все это происходит до тех пор, пока это не мешает гуглу. И с каждым годом порочный круг разорвать будет все труднее. По этому как по мне - то что по силам каждому уже сейчас - осознанно выбирать важнейшие продукты и отдавать предпочтение open source. Это то что я делаю крайнее время, и этой идеей хотел поделиться (я явно не первооткрыватель, просто хотел поднять еще раз тему). И для меня лучше делать что-то, чем совсем ничего)
Вполне возможно, однако например на пару с кем-то поделить рынок вероятно сможет без проблем. Как сделал это Google Play и AppStore. Или как Visa (57%) и MasterCard (26%, кстати проценты похожи на Chrome и Safari). Intel и AMD, и так далее. Сейчас условный Google получает все без проблем, и ему нет смысла меняться. Если рынок (пользователи) не предпримут никаких шагов, то ситуация так и продолжит развиваться. По этому выбор альтернативных вариантов по мне может изменить ситуацию, если значительная часть пользователей будет выбирать другие продукты, то это будет причина для Google чтобы пересмотреть правила игры, а в идеале, как я убежден, рынок должен устанавливать правила, а не отдельные игроки
Я согласен что идея про цивилизованные способы передачи данных хорошая, однако суть статьи несколько в другом. По моему мнению критически важные для большого количества людей продукты должны быть открыты и таким образом менее зависимы от одной компании. Что очень трудно представить в сегодняшнем мире. По этому идея осознанного выбора продуктов на сегодня мне кажется более перспективной.
Вы правы, сегодня гугл зарабатывает рекламой, но кто может сказать, что будет завтра? Я думаю история предоставила достаточно примеров, когда монопольное владение чем-либо в конечном счете заканчивалось огромными проблемами для людей. В конце концов рынок формируют именно пользователи, и они должны устанавливать правила игры, а иначе при монополизме выходит что весь рынок играет по правилам нескольких крупных игроков
Сразу видно как внимательно прочитали статью. Я указал ссылку на утилиту, которая позволяет это сделать в ваш один клик, и указал почему не рекомендую ее использовать. Критикуешь - предлагай. Вместо голословности поделитесь проверенными вариантами и я добавлю их в статью
Да, абсолютно верно. Создать класс наследник и далее можно расширить стили и/или переопределить шаблон. Пример расширения стилей. Тоже касается и шаблона. Просто создать twig шаблон. Twig также поддерживает расширение, по-этому можно расширить (extend) родительский шаблон и переопределить только его часть
Спасибо за уточнение, не сталкивался с Yii, посмотрел, у них пожалуй самые развитые блоки (виджеты) из подобных, но насколько я понял это не самостоятельное решение, и отличается по функционалу с пакетом, по-этому желающие (например я) не смогут использовать это как альтернативу.
Это суффиксы, чтобы отметить Controller-ы для автозагрузки, модель Article, а контроллер ArticleC. Использовать 'Controller' целиком как суффикс было бы слишком многословно при большом количестве блоков.
Интересная мысль, изначально разделил чтобы не смешивать данные и зависимости, но если рассматривать в контексте блока (виджета) как целую сущность то это имеет смысл. Подумаю над этим.
Можете пояснить, что именно могло бы создаваться автоматически?
Тогда сама идея изменится. Благодаря ограничениям нет необходимости указывать каждый раз путь к шаблону, нет необходимости указывать класс модели для контроллера. Не вижу ничего плохого в наследовании, тем более что наследники будут решать четко установленные задачи. И использование protected полей класса вместо прямого массива (как например в в symfony) дает ряд преимуществ
В привычном прямом понимании да. Данные имена были выбраны чтобы люди знакомые с MVC могли провести аналогии. Если рассматривать каждый блок в отдельности, то Model ожидаемо предоставляет данные, View (twig) их отображает, а Controller управляет зависимостями
Если не трудно, хотелось бы пару примеров из кода с альтернативной версией (правильной по вашему)
абсолютно согласен, однако в данном случае наследование необходимо для чисто технического момента, как чтение полей, и ничего более. И разделение: модель — отображение — контроллер для распределения ответственности по-моему в данном пакете реализовано довольно прозрачно.
А зачем? Пакету необходимо указать лишь одну родительскую директорию, а поддиректорий может быть сколько угодно. Я думаю для большинства случаев этого будет достаточно.
У вас есть конкретные предложения по этому поводу?
Это совпадает с BEM и мне кажется более удобным, чем разделение по типам файлов. Касательно одинаковых имен, да, технически это возможно, но я исходил из удобства редактирования (имхо), в случае одинаковых имен когда в IDE будут открыты одновременно несколько блоков различать их будет менее удобно, и опять же текущий способ более похож на BEM и будет более привычен для тех кто знаком с ним. Копирование блоков я использую довольно часто, в каждом проекте есть дефолтный блок и я создаю блоки с него, чтобы избежать ненужной рутины. По-этому в пакете также есть команда для копирования блоков с заменой имен