Спасибо за статью. Но не удержусь от пары замечаний.
Ошибку валидации вряд ли нужно логировать. Это, по сути, не ошибка, а совершенно ожидаемое поведение. Да, там останется только перевыброс исключения. И как раз на этом стоит остановиться поподробнее
Код не станет сложнее, если Exception поменять на ServiceValidationException и DomainValidationException, но зато станет куда более логичным и приближённым к реальности. А сейчас смотришь, и не понимаешь, почему ошибка, к примеру, соединения базы данных возвращает 400, а не 500 статус
И вот тут как раз и объяснить, почему вы меняем DomainValidationException на ServiceValidationException
Ну и совсем уж по мелочи
ошибку "Не корректная сумма денег" надо заменить на "Некорректная валюта" (и в целом надо бы вычитать на грамматические ошибки и опечатки)
проверка на empty($this->value) не имеет смысла, её стоит убрать
Во-первых, не у меня, а у автора статьи. Во-вторых, это требует нулевого порога входа и делается один раз копипастой. В-третьих, любой шаблонизатор требует инициализации и начальной конфигурации, то есть конкретно этот ничем не отличается от всех других. Ну разве что привязкой к модели, но её делать не обязательно.
И главное - верстальщик-то здесь при чём? Который к этим "премудростям" не имеет ни малейшегоо отношения. Подключение и инициализация движка - это на 100% работа бэкендера.
Ради чего всё это?
Вы так и не предложили альтернативу, в которой "всего этого" нету.
Юзеркейс: верстальщик в гробу видал этот ваш SSR и желает всё отрендерить на VUEjs.
В этом случае шаблоны вообще не при чём, а весь вывод делается в том самом Vue. Это отдельный юзкейс. Смешивающего серверную шаблонизацию и SSR гения, который героически решает задачу создания json из переменных шаблона вы себе выдумали сами, к данной статье он не имеет отношения. Ну или если вам реально приходилось с этим сталкиваться в жизни, я вам искренне сочувствую, но нормальные люди отправляют json сразу с сервера. Поэтому снова прошу не путать свой печальный опыт с предметом статьи.
Такое ощущение, что половину комментариев сюда пишет ИИ.
Что именно вы считаете "слишком многими телодвижениями"? Синтаксис шаблона? Код подключения шаблонизатора? Композер? И какая, по-вашему, "вставка переменных в шаблон" не требует этих телодвижений? "похапе инклюде"? При чем тут тогда трогательная забота о "верстальщике", который именно в этом случае и "будет обязан обладать знаниями всех этих PHP премудростей"? А в случае с шаблонизатором ему как раз надо будет знать только его примитивный синтаксис.
Как говорится, "но кто-то же написал 3 миллиона доносов". Увы, именно аудитория Хабра, радостно хавающая очередной кликбейт, и выводит цыганщину в топ. Ещё несколько лет назад такой высер не поднялся бы выше чулана. А сейчас автор радостно льёт трафик как на ютуб, так и в телегу. Профит!
Наоборот. Mustashe, к сожалению - это другая крайность, попытка спрятать в голову в песок и заявить, что логики отображения не существует. Очень хороший пример ситуации, когда противоречия между идеологией и реальностью решаются попытками подогнать реальность под идеологию. С закономерно анекдотическим результатом.
Как в Mustashe выглядит цикл? {{#block}}...{{/block}}. А условный переход?... {{#block}}...{{/block}}. Гениально, Ватсон! Буквально как в анекдоте, "В теории мы миллионеры", а в реальности логика в шаблоне есть, но при этом чудовищно нечитабельная: вместо явного цикла или явного условия - совершенно одинаковый синтаксис, суть которого можно понять только посмотрев тип переменной (и который гвоздями прибит к именам переменных). А дальше начинаются совсем уже танцы вприсядку со специальными именами блоков, типа block_has_items.
Для любого непредвзятого наблюдателя все эти "logicless" шаблонизаторы - просто анекдот.
Автоматическое экранирование. Преимущество конкретно этого малюсенького кусочка кода в том, что он не идентичен примеру ниже, который для соответствия должен выглядеть как
здесь мы убиваем сразу двух зайцев - самых беспечных (которые либо не знают, либо забывают про обязательное форматирование вывода в зависимости от контекста) и самых умных (которые считают, что некоторые переменные и так безопасные и их форматировать не обязательно. И хотя автоматическое форматирование не панацея, и имеет уже свои недостатки, это огромный шаг вперёд по сравнению с вашим <?=item['caption']?>.
Наследование и блоки. В реальной жизни шаблоны оказываются чуть сложнее, чем ваш пример. Особенно - шаблон основного дизайна сайта, в котором бывает множество мелких исключений. Например, на определённой странице надо подгрузить специальный js или css. Или есть сайдбар, который в каждом разделе сайта отображает свою информацию. В чистом пхп такой сайдбар очень быстро превращается в кучу говнокода. А при использовании шаблонизатора мы в основном шаблоне заполняем этот блок дефолтной информацией, а в шаблоне конкретной страницы мы можем заменить или дополнить её.
Разделение ответственности. Увы, не каждый шаблонизатор может похвастаться следованием этому правилу - как, например, рассматриваемый в этой статье (что также снижает его привлекательность). Разделение это нужно не "контентнику" а самому программисту, который, если дать ему возможность писать в шаблоне на РНР, тут же перетянет половину бизнес-логики в шаблон. А потом кто-то другой будет мучаться, переводя сайт на новый дизайн или на SPA.
Потрясающая производительность. Абсолютно непонятно, за счёт чего, если там везде чистый пхп. Я добавил в эти копеечные шаблоны HTML с главной страницы php.net, просто чтобы немного приблизить их к реал лайф. Результаты: 39.46 ms: Twig (with cache) 142.79 ms: Blade from Laravel (with cache) 205.84 ms: PHP Views without Models (using built-in Blade) внезапно потрясающая производительность вся куда-то улетучилась.
Отсутствие зависимостей. Ну да, а другие пакеты ставятся с трудом и страданиями.
Широкая совместимость на самом деле абсолютно стандартная
Надежная архитектура: баззворд
Поддержка пространств имён какая-то внутренняя фишка, которая в других шаблонизаторах не нужна.
Плюс какие-то прибитые гвоздями к шаблонам модели
Ну и подписывайтесь на наш телеграм канал поставьте нам звездочку, а то их там всего три штуки, то есть весь этот матёрый проект видело человек 5.
Ну, справедливости ради, вы не здесь упоминаете плату за канал. Хотя конечно "прицепился к существующему" тоже вариант, особенно когда захотел пару фильмов с торрентов скачать :)
Namescheap берёт $15 за домен в год. Вообще, советую не вестись на всякие "домен бесплатно" и "впридачу". В итоге вы им не владеете - и, соответственно, теряете при попытке сменить провайдера. Домен надо регать отдельно и на себя. И потом привязывать к сервису. Вот как автор пишет в статье - бесплатный хостинг но на собственном домене.
Для не самых новых версий это правда. Но вот для ископаемых ситуация меняется на противоположную - как раз их-то и не найдёшь. Плюс стон стоит на весь интернет, когда такие вот сидельцы рыдают, что хостер насильно обновил версию пхп до минимально приемлемой и их говнокод перестал работать. Это всё равно что рекомендовать Питон 2.
Да и чисто технически, в чём смысл зачем рекомендовать 7.2 и давать ссылку, по которой эту версию скачать невозможно. Плюс в целом непонятно, зачем вообще рекомендовать какую-то конкретную версию, если никакие специфические для этой версии возможности языка не используются, а не оставить версию на выбор читателя.
Я стараюсь читать только подписки, вкладка "Моя лента". Уже довольно давно попытки открывать "Все потоки" (в любом формате) приводят только к фрустрации. Есть ещё правда сайдбар, в который попадает самый отборный шлак, но есть технические средства и от него избавиться. Я понимаю, что это страусиная политика, но нервы дороже.
Используя имя файла как ключ поиска в файловой системе (а никакого другого штатного назначения у имени файла нет)
Чушь какая-то. Тут перемешаны собственно поиск и обращение по имени. Чтобы обратиться к файлу по имени, его надо знать. Посмотреть его в каталоге например. И здесь никакая независимость не нужна - что увидел, то и написал.
Поиск же вида "вроде как-то так назывался", который заведомо может вернуть больше одного имени, это совсем другая, внешняя по отношению к реализации ФС задача. В которой можно реализовать и независимость, и созвучие и что угодно ещё. Посмотрев результаты этого поиска, можно найти нужный файл, и обратиться к нему по имени. Регистрозависимому.
Статья - какой-то позор. Что, впрочем, для этого блога скорее норма. Писал зумер, который скайп видел только на картинке, и вообще ничего не понял про исходный скайп. Как и про последствия продажи. Про "синоним видеосвязи" в 2003 и "Skype начал терять форму — особенно хорошо это стало заметно после того, как его купила Microsoft" мог написать либо ИИ, либо копирайтер-борзописец, который умеет ставить одни слова рядом с другими, но понимание их смысла в его обязанности не входит.
Как фанату РНР, мне очень приятно видеть такие новости. Велкам, как говорится, ту зе клаб. Впрочем, как фанат РНР, который уже лет 15 слышит о том, что язык выходит "из моды", я бы не слишком торопился этим новостям доверять.
Ну вот скажем перл и кобол у них в двадцатке. И я вполне готов предположить, что людям, работающим с этими языками, привычнее традиционные способы получения ответов на вопросы.
А в целом, я бы скорее поставил под вопрос алгоритмы Тиобе, чем популярность Котлина.
Тема очень интересная, и я очень надеюсь, что найдётся достойный соперник от Filament. Я бы даже ради этого расширил аудиторию и на англоязычный интернет. Вот только хорошо бы у статьи вынести слово "Батл" в заголовок. Так она становится гораздо интереснее, и нет рефлекторного ощущения "о, кто-то опять свою админку пиарит", которое прочно ассоциируется с заголовками вида "ХХХ или УУУ?".
Обычно это делается не из-за этих детских страхов, а банально из-за репликации/балансировки - записи идут в мастер, а чтение делается со слейвов. Отсюда разные соединения для чтения и записи.
Спасибо за статью. Но не удержусь от пары замечаний.
Ошибку валидации вряд ли нужно логировать. Это, по сути, не ошибка, а совершенно ожидаемое поведение. Да, там останется только перевыброс исключения. И как раз на этом стоит остановиться поподробнее
Код не станет сложнее, если Exception поменять на ServiceValidationException и DomainValidationException, но зато станет куда более логичным и приближённым к реальности. А сейчас смотришь, и не понимаешь, почему ошибка, к примеру, соединения базы данных возвращает 400, а не 500 статус
И вот тут как раз и объяснить, почему вы меняем DomainValidationException на ServiceValidationException
Ну и совсем уж по мелочи
ошибку "Не корректная сумма денег" надо заменить на "Некорректная валюта" (и в целом надо бы вычитать на грамматические ошибки и опечатки)
проверка на empty($this->value) не имеет смысла, её стоит убрать
Во-первых, не у меня, а у автора статьи. Во-вторых, это требует нулевого порога входа и делается один раз копипастой. В-третьих, любой шаблонизатор требует инициализации и начальной конфигурации, то есть конкретно этот ничем не отличается от всех других. Ну разве что привязкой к модели, но её делать не обязательно.
И главное - верстальщик-то здесь при чём? Который к этим "премудростям" не имеет ни малейшегоо отношения. Подключение и инициализация движка - это на 100% работа бэкендера.
Вы так и не предложили альтернативу, в которой "всего этого" нету.
В этом случае шаблоны вообще не при чём, а весь вывод делается в том самом Vue. Это отдельный юзкейс. Смешивающего серверную шаблонизацию и SSR гения, который героически решает задачу создания json из переменных шаблона вы себе выдумали сами, к данной статье он не имеет отношения. Ну или если вам реально приходилось с этим сталкиваться в жизни, я вам искренне сочувствую, но нормальные люди отправляют json сразу с сервера. Поэтому снова прошу не путать свой печальный опыт с предметом статьи.
Такое ощущение, что половину комментариев сюда пишет ИИ.
Что именно вы считаете "слишком многими телодвижениями"? Синтаксис шаблона? Код подключения шаблонизатора? Композер? И какая, по-вашему, "вставка переменных в шаблон" не требует этих телодвижений? "похапе инклюде"? При чем тут тогда трогательная забота о "верстальщике", который именно в этом случае и "будет обязан обладать знаниями всех этих PHP премудростей"? А в случае с шаблонизатором ему как раз надо будет знать только его примитивный синтаксис.
Как говорится, "но кто-то же написал 3 миллиона доносов". Увы, именно аудитория Хабра, радостно хавающая очередной кликбейт, и выводит цыганщину в топ. Ещё несколько лет назад такой высер не поднялся бы выше чулана. А сейчас автор радостно льёт трафик как на ютуб, так и в телегу. Профит!
Наоборот.
Mustashe, к сожалению - это другая крайность, попытка спрятать в голову в песок и заявить, что логики отображения не существует. Очень хороший пример ситуации, когда противоречия между идеологией и реальностью решаются попытками подогнать реальность под идеологию. С закономерно анекдотическим результатом.
Как в Mustashe выглядит цикл?
{{#block}}...{{/block}}. А условный переход?...{{#block}}...{{/block}}. Гениально, Ватсон! Буквально как в анекдоте, "В теории мы миллионеры", а в реальности логика в шаблоне есть, но при этом чудовищно нечитабельная: вместо явного цикла или явного условия - совершенно одинаковый синтаксис, суть которого можно понять только посмотрев тип переменной (и который гвоздями прибит к именам переменных). А дальше начинаются совсем уже танцы вприсядку со специальными именами блоков, типаblock_has_items.Для любого непредвзятого наблюдателя все эти "logicless" шаблонизаторы - просто анекдот.
Спасибо за хороший вопрос. Основных причин три
Автоматическое экранирование. Преимущество конкретно этого малюсенького кусочка кода в том, что он не идентичен примеру ниже, который для соответствия должен выглядеть как
здесь мы убиваем сразу двух зайцев - самых беспечных (которые либо не знают, либо забывают про обязательное форматирование вывода в зависимости от контекста) и самых умных (которые считают, что некоторые переменные и так безопасные и их форматировать не обязательно.
И хотя автоматическое форматирование не панацея, и имеет уже свои недостатки, это огромный шаг вперёд по сравнению с вашим
<?=item['caption']?>.Наследование и блоки. В реальной жизни шаблоны оказываются чуть сложнее, чем ваш пример. Особенно - шаблон основного дизайна сайта, в котором бывает множество мелких исключений. Например, на определённой странице надо подгрузить специальный js или css. Или есть сайдбар, который в каждом разделе сайта отображает свою информацию. В чистом пхп такой сайдбар очень быстро превращается в кучу говнокода. А при использовании шаблонизатора мы в основном шаблоне заполняем этот блок дефолтной информацией, а в шаблоне конкретной страницы мы можем заменить или дополнить её.
Разделение ответственности. Увы, не каждый шаблонизатор может похвастаться следованием этому правилу - как, например, рассматриваемый в этой статье (что также снижает его привлекательность). Разделение это нужно не "контентнику" а самому программисту, который, если дать ему возможность писать в шаблоне на РНР, тут же перетянет половину бизнес-логики в шаблон. А потом кто-то другой будет мучаться, переводя сайт на новый дизайн или на SPA.
Чисто по подаче выглядит, как инфоцыганство.
Потрясающая производительность. Абсолютно непонятно, за счёт чего, если там везде чистый пхп. Я добавил в эти копеечные шаблоны HTML с главной страницы php.net, просто чтобы немного приблизить их к реал лайф. Результаты:
39.46 ms: Twig (with cache)
142.79 ms: Blade from Laravel (with cache)
205.84 ms: PHP Views without Models (using built-in Blade)
внезапно потрясающая производительность вся куда-то улетучилась.
Отсутствие зависимостей. Ну да, а другие пакеты ставятся с трудом и страданиями.
Широкая совместимость на самом деле абсолютно стандартная
Надежная архитектура: баззворд
Поддержка пространств имён какая-то внутренняя фишка, которая в других шаблонизаторах не нужна.
Плюс какие-то прибитые гвоздями к шаблонам модели
Ну и
подписывайтесь на наш телеграм каналпоставьте нам звездочку, а то их там всего три штуки, то есть весь этот матёрый проект видело человек 5.Ну, справедливости ради, вы не здесь упоминаете плату за канал. Хотя конечно "прицепился к существующему" тоже вариант, особенно когда захотел пару фильмов с торрентов скачать :)
Namescheap берёт $15 за домен в год. Вообще, советую не вестись на всякие "домен бесплатно" и "впридачу". В итоге вы им не владеете - и, соответственно, теряете при попытке сменить провайдера. Домен надо регать отдельно и на себя. И потом привязывать к сервису. Вот как автор пишет в статье - бесплатный хостинг но на собственном домене.
Для не самых новых версий это правда. Но вот для ископаемых ситуация меняется на противоположную - как раз их-то и не найдёшь. Плюс стон стоит на весь интернет, когда такие вот сидельцы рыдают, что хостер насильно обновил версию пхп до минимально приемлемой и их говнокод перестал работать. Это всё равно что рекомендовать Питон 2.
Да и чисто технически, в чём смысл зачем рекомендовать 7.2 и давать ссылку, по которой эту версию скачать невозможно. Плюс в целом непонятно, зачем вообще рекомендовать какую-то конкретную версию, если никакие специфические для этой версии возможности языка не используются, а не оставить версию на выбор читателя.
Очевидно же - в реферальной ссылке :) Банальное SEO.
Я стараюсь читать только подписки, вкладка "Моя лента". Уже довольно давно попытки открывать "Все потоки" (в любом формате) приводят только к фрустрации. Есть ещё правда сайдбар, в который попадает самый отборный шлак, но есть технические средства и от него избавиться. Я понимаю, что это страусиная политика, но нервы дороже.
Чушь какая-то. Тут перемешаны собственно поиск и обращение по имени. Чтобы обратиться к файлу по имени, его надо знать. Посмотреть его в каталоге например. И здесь никакая независимость не нужна - что увидел, то и написал.
Поиск же вида "вроде как-то так назывался", который заведомо может вернуть больше одного имени, это совсем другая, внешняя по отношению к реализации ФС задача. В которой можно реализовать и независимость, и созвучие и что угодно ещё. Посмотрев результаты этого поиска, можно найти нужный файл, и обратиться к нему по имени. Регистрозависимому.
Не помню, спрашивал ли уже - а на английском этих статей нету? Они заслуживают куда более широкой аудитории, чем полудохлый Хабр.
Статья - какой-то позор. Что, впрочем, для этого блога скорее норма. Писал зумер, который скайп видел только на картинке, и вообще ничего не понял про исходный скайп. Как и про последствия продажи. Про "синоним видеосвязи" в 2003 и "Skype начал терять форму — особенно хорошо это стало заметно после того, как его купила Microsoft" мог написать либо ИИ, либо копирайтер-борзописец, который умеет ставить одни слова рядом с другими, но понимание их смысла в его обязанности не входит.
Впрочем, пипл хавает, денежки идут. Что ещё надо?
Как фанату РНР, мне очень приятно видеть такие новости. Велкам, как говорится, ту зе клаб. Впрочем, как фанат РНР, который уже лет 15 слышит о том, что язык выходит "из моды", я бы не слишком торопился этим новостям доверять.
Ну вот скажем перл и кобол у них в двадцатке. И я вполне готов предположить, что людям, работающим с этими языками, привычнее традиционные способы получения ответов на вопросы.
А в целом, я бы скорее поставил под вопрос алгоритмы Тиобе, чем популярность Котлина.
Заголовок: выпустила
Текст: собирает предварительные заказы и планирует открыть кампанию на кикстартер (то есть нет ни даже прототипа, ни денег на него. Только картинки).
Информационная служба Хабра такая информационная
Тема очень интересная, и я очень надеюсь, что найдётся достойный соперник от Filament. Я бы даже ради этого расширил аудиторию и на англоязычный интернет. Вот только хорошо бы у статьи вынести слово "Батл" в заголовок. Так она становится гораздо интереснее, и нет рефлекторного ощущения "о, кто-то опять свою админку пиарит", которое прочно ассоциируется с заголовками вида "ХХХ или УУУ?".
Обычно это делается не из-за этих детских страхов, а банально из-за репликации/балансировки - записи идут в мастер, а чтение делается со слейвов. Отсюда разные соединения для чтения и записи.