Он решает проблему экранирования и проблему случайного его отсутствия, этого достаточно. Данные выведутся экранированными, либо не выведутся совсем. С остальными видами экранирования такой проблемы нет — если вывести массив или объект в JS без json_encode, то будет просто ошибка в скрипте.
Заставлять никого не надо, кому нужно — будет использовать, кому не нужно — все останется как есть.
Вот уж чего в PHP точно не нужно, так это полноценный шаблонизатор. Его можно просто взять и подключить. Я предлагаю отдельный оператор только потому, что это самая частая операция при выводе данных без шаблонизатора, а ее неиспользование приводит к проблемам в безопасности.
Для того, чтобы робот сочинял более адекватные стихи или понимал глубокий смысл уже написанных, следует вложить в него систему ассоциирования
Для того, чтобы робот понимал смысл (не обязательно глубокий), нужно, чтобы он мог распознавать окружающие объекты и связи между ними, а также восстанавливать их в воображении в оперативной памяти по описанию. От того, что он скажет «word1 у меня ассоциируется с word2», он не станет больше понимать значение этих слов.
А главное — оператор покрывает все кейсы связанные со сравнением. Ваш же хорошо если 80% случаев покрывает.
Ну это уже демагогия) А «мой оператор» покрывает 100% случаев, связанных с экранированием вывода в HTML. Если вы не используете экранирование HTML, оно не теряет полезности для тех, кто его использует. А специальный оператор — это сокращение для этой частой операции. В проектах без шаблонизаторов экранирование в местах текущего использования <?= ?> нужно даже не в 80, а примерно в 99% случаев.
Кстати, если вы не используете экранирование, то этот оператор на ваши проекты не повлияет вообще никак. А тем, кто использует, поможет повысить безопасность и уменьшить копи-пасту одних и тех же вызовов.
все равно рано или поздно придется отказываться от этого в пользу функций хэлперов.
Например в каких случаях? Я снова прошу вас привести пример кода. Если задача будет связана с выводом в HTML, то и экранирование никуда не денется, независимо от дополнительной обработки через urlencode, json_encode или something_else_encode.
А еще можно поступить вообще круто, перестать использовать php как шаблонизатор и взять какой twig.
Речь не о том, нужны шаблонизаторы или нет. Я согласен с тем, что лучше использовать их. Есть проекты без них, и во многих случаях перейти на шаблонизатор уже нет возможности.
Ну то что он зависит от контекста, я сам написал в статье. Тильда это уже детали реализации. С экранирующими функциями есть некоторая проблема с автозагрузкой, я писал выше. И проблема не в длине, я про это тоже писал.
… должно быть еще и HTML-encoded. Это написано у них в таблице
text | Default for content inside elements | Encodes all HTML special characters.
attribute | Default for attribute values | Encodes all HTML special characters.
… и об этом я и писал в статье.
Многие элементы из этой таблицы не используются совместно с PHP. Например styleComment — часто вы встречаете генерацию комментов в теге style через PHP?
вы снова пытаетесь логику закинуть туда, где её не должно быть
Это тема отдельного разговора. У представления есть своя внутренняя логика отображения. Не нужно путать ее с бизнес-логикой.
Скрытый текст
Пример — одни и те же данные (из сервиса их получения) можно представить и в виде таблицы, и в виде чарта, а в таблице сделать строку «Итого» вверху, внизу, либо и там и там, а так же еще и в тексте перед таблицей изложить, а для разных чартов сгруппировать данные по-разному. Предлагаете все эти знания, касающиеся отображения, поместить в контроллер или бизнес-логику?
Есть операторы, которые используются гораздо реже. Если бы их не было, я бы не стал поднимать этот вопрос. Опять же есть более короткие записи для уже существующих операторов. Вместо тернарного оператора можно использовать if, вместо <?= ?> оператор <?php echo ?>. Но ни у кого не вызывает вопросов необходимость их наличия в языке.
Универсальное экранирование для всех случаев в принципе невозможно придумать. Делать возможность добавлять свои эскейперы технически сложно, да и не нужно. Это как раз к тому вопросу, что не стоит превращать язык в шаблонизатор. Раз-другой можно и вручную указать. Если это часто используется в каком-то отдельном проекте, то нужно действительно взять специализированный движок для шаблонов. Но на фоне общего числа проектов на PHP проекты с кастомными эскейперами это очень незначительная часть.
Нет, я имел в виду пример, который может привести к проблемам в безопасности и/или нарушению разметки. Эти флаги для разных стандартов HTML различаются набором дополнительных сущностей. Насколько я понимаю, для правильного формирования разметки достаточно преобразовывать 5 базовых сущностей.
а в практике другого человека не самый частый, он бы хотел
Для этого и нужен процесс RFC. Кроме того, речь идет не об одном человеке, а о наиболее частом случае использования языка. Думаю, никто не будет отрицать, что PHP чаще всего применяется для веб-програмирования и обработки гипертекста.
Да и способов экранировать тот же HTML множество, в разных случаях могут понадобиться разные.
Приведите пример.
Следовательно, htmlspecialchars не обязателен для экранирования строк для JS.
Я про это и писал в статье. Это не универсальный оператор экранирования, он предназначен специально для контекста HTML. Потому что вывод в HTML делается во много раз чаще, чем передача переменых в JS, и потому что он может применяться совместно с другими контекстами, а не вместо них. Это просто замена постоянному вызову htmlspecialchars.
Приведите пример, как это можно сделать. Даже с преобразованием даты будут проблемы — если для дэйтпикера нужен один формат с полным названием месяца на текущем языке пользователя, а в hidden-поле нужен другой технический формат, который можно отправить на сервер. Или другой пример — когда передается объект user, а свойство user->fullName это геттер, который конкатенирует отдельные составляющие имени.
так как экранировать можно в миллионах разных вариаций
Этот оператор не является супер-универсальным оператором на все случаи жизни. Как раз потому что такой оператор сделать нельзя. В этих вариациях есть 2 части — одна зависит от задачи, другая от внешнего контекста. Миллион вариаций — это про первую часть, а вторая у нас всегда HTML, исключения из этого правила описаны в статье. Для нее и нужен этот оператор.
Конкретные флаги это уже детали реализации. Думаю, нужно делать такие, которые используются в большинстве крупных фреймворков. Сейчас вопрос в том, нужно ли наличие такого специализированного оператора для HTML контекста.
Проекты с его использованием никуда не денутся, и для них также надо будет писать код.
Можно написать либо одну конструкцию, либо другую. А хелпер-функцию можно написать либо нет независимо от начала конструкции. И вероятность забыть применить все-таки немного меньше, потому что эта конструкция должна применяться при любом выводе в HTML, и если у вас везде в файле встречается <?~ ?>, то надо задуматься, зачем ставить другой оператор. Также обычно просто копи-пастят, и копи-паста в данном случае будет помогать.
Это один частный случай, но и самый частый. Он встречается даже чаще, чем конструкции для ?? и <=>.
Вообще, слово "частный" здесь не очень подходит. Если бы контексты были взаимоисключающими, тогда да. А так этот частный случай используется вместе с другими частными случаями. Причем используется он всегда, за исключением тега script, но внутри тега скрипт ничего и работать не будет, если мы выведем туда объект через htmlspecialchars.
Если будет лишний пробел, то ничего не выведется, и это будет заметно. А также для этого надо короткие теги включить.
Можете привести конкретный пример возможных проблем с кодом на PHP?
а если случайно его не повторить, то это приводит к проблемам в безопасности.
Именно поэтому я против <?~ ?>
Это взаимоисключающие операторы, можно написать либо <?~ ?>, либо <?= ?>, иначе не будет работать.
А с отдельной функцией это совместное использование, можно написать начало <?=, а потом либо продолжить, либо нет.
Я вообще не очень понимаю вашу логику. Введение специального оператора для экранирования в каком-либо контексте как минимум не уменьшит безопасность, потому что это не влияет на старый код и старые операторы.
Это не будет работать: если кто-то использует "=" вместо "~" по ошибке, то автоэкранирования не будет.
А если кто-то в Twig по ошибке скопипастит длинный оператор с | raw в конце, то тоже экранирования не будет.
От ошибок никто не застрахован, это не аргумент. Я упомянул про это не в качестве аргумента за или против, а чтобы показать отличие. Если кто-то использует =, то будет точно так же, как сейчас. А новый оператор позволит уменьшить количество вариантов, где можно совершить ошибку.
Элементарно. Ставится директива: все новые шаблоны и исправление старых — только на twig.
Это абсолютно никак не уменьшает сложность перевода. Как нарисовать сову? Элементарно — ставится директива: нарисовать сову.
Почему тогда просто не использовать нормальный качественный шаблонизатор?
Есть такие проекты, это факт. Для них нужно писать код, это тоже факт. Не думайте только о себе.
Речь не о том, нужны шаблонизаторы или нет. Шаблонизаторы вещь полезная, это тоже факт.
Вы предлагаете ввести средство, которое пригодится лишь в коде плохого качества.
Отсутствие шаблонизатора не означает код плохого качества.
Дело не в том, что и где можно заменить. а в том, что часто повторяется одно и то же действие, а если случайно его не повторить, то это приводит к проблемам в безопасности.
Этот способ в бесконечное количество раз лучше того, который предложили вы.
Предложите пожалуйста такой же бесконечно простой способ перевести 100500 работающих шаблонов в большом внутреннем проекте компании с PHP на Twig.
И оба эти способа без автоматического экранирования плохие
<?~ ?> и есть способ с автоматическим экранированием.
Последний раз я <?= ?> встречал три года назад, работая с легаси-проектом.
Поэтому в статье я специально обратил внимание на то, что требуется мнение людей, которые реально работают с проектами без шаблонизаторов.
А давайте введём register_globals обратно, объявим неймспейсы и классы deprecated
Не вижу связи. Для введения неймспейсов и других нововведений были свои причины. Причины для появления такого оператора я изложил в статье. Он не уменьшает безопасность и не увеличивает длину названий в коде, как раз наоборот.
Ваше обоснование в том, что можно сделать специальную функцию. Но проблема не в том, что у нас нет функции, а в том, что часто повторяется одно и то же действие, а если случайно его не повторить, то это приводит к проблемам в безопасности.
Но проблема с функцией немного шире. Как обеспечить глобальную доступность экранирующей функции в каждом файле представления? Делать дополнительный include_once / require_once при каждом рендеринге шаблона? Подключать один раз при старте приложения, независимо от того, будем мы рендерить HTML или нет? Автозагрузки функций в PHP еще нет, это пока только на стадии RFC.
Заставлять никого не надо, кому нужно — будет использовать, кому не нужно — все останется как есть.
Для того, чтобы робот понимал смысл (не обязательно глубокий), нужно, чтобы он мог распознавать окружающие объекты и связи между ними, а также восстанавливать их
в воображениив оперативной памяти по описанию. От того, что он скажет «word1 у меня ассоциируется с word2», он не станет больше понимать значение этих слов.Ну это уже демагогия) А «мой оператор» покрывает 100% случаев, связанных с экранированием вывода в HTML. Если вы не используете экранирование HTML, оно не теряет полезности для тех, кто его использует. А специальный оператор — это сокращение для этой частой операции. В проектах без шаблонизаторов экранирование в местах текущего использования <?= ?> нужно даже не в 80, а примерно в 99% случаев.
Кстати, если вы не используете экранирование, то этот оператор на ваши проекты не повлияет вообще никак. А тем, кто использует, поможет повысить безопасность и уменьшить копи-пасту одних и тех же вызовов.
Например в каких случаях? Я снова прошу вас привести пример кода. Если задача будет связана с выводом в HTML, то и экранирование никуда не денется, независимо от дополнительной обработки через urlencode, json_encode или something_else_encode.
Речь не о том, нужны шаблонизаторы или нет. Я согласен с тем, что лучше использовать их. Есть проекты без них, и во многих случаях перейти на шаблонизатор уже нет возможности.
& copy ;? Это полезное замечание конечно. Но основная цель — уменьшить повторяющиеся действия и повысить безопасность. Поэтому я и попросил привести пример, в котором будет видно именно проблему с применением.… должно быть еще и HTML-encoded. Это написано у них в таблице
… и об этом я и писал в статье.
Многие элементы из этой таблицы не используются совместно с PHP. Например styleComment — часто вы встречаете генерацию комментов в теге style через PHP?
Это тема отдельного разговора. У представления есть своя внутренняя логика отображения. Не нужно путать ее с бизнес-логикой.
Универсальное экранирование для всех случаев в принципе невозможно придумать. Делать возможность добавлять свои эскейперы технически сложно, да и не нужно. Это как раз к тому вопросу, что не стоит превращать язык в шаблонизатор. Раз-другой можно и вручную указать. Если это часто используется в каком-то отдельном проекте, то нужно действительно взять специализированный движок для шаблонов. Но на фоне общего числа проектов на PHP проекты с кастомными эскейперами это очень незначительная часть.
Для этого и нужен процесс RFC. Кроме того, речь идет не об одном человеке, а о наиболее частом случае использования языка. Думаю, никто не будет отрицать, что PHP чаще всего применяется для веб-програмирования и обработки гипертекста.
Приведите пример.
Я про это и писал в статье. Это не универсальный оператор экранирования, он предназначен специально для контекста HTML. Потому что вывод в HTML делается во много раз чаще, чем передача переменых в JS, и потому что он может применяться совместно с другими контекстами, а не вместо них. Это просто замена постоянному вызову htmlspecialchars.
Этот оператор не является супер-универсальным оператором на все случаи жизни. Как раз потому что такой оператор сделать нельзя. В этих вариациях есть 2 части — одна зависит от задачи, другая от внешнего контекста. Миллион вариаций — это про первую часть, а вторая у нас всегда HTML, исключения из этого правила описаны в статье. Для нее и нужен этот оператор.
Ок, как по-вашему они должны быть написаны? Приведите конкретный код, пожалуйста.
Вообще, слово "частный" здесь не очень подходит. Если бы контексты были взаимоисключающими, тогда да. А так этот частный случай используется вместе с другими частными случаями. Причем используется он всегда, за исключением тега script, но внутри тега скрипт ничего и работать не будет, если мы выведем туда объект через htmlspecialchars.
Можете привести конкретный пример возможных проблем с кодом на PHP?
Это взаимоисключающие операторы, можно написать либо <?~ ?>, либо <?= ?>, иначе не будет работать.
А с отдельной функцией это совместное использование, можно написать начало <?=, а потом либо продолжить, либо нет.
Я вообще не очень понимаю вашу логику. Введение специального оператора для экранирования в каком-либо контексте как минимум не уменьшит безопасность, потому что это не влияет на старый код и старые операторы.
А если кто-то в Twig по ошибке скопипастит длинный оператор с | raw в конце, то тоже экранирования не будет.
От ошибок никто не застрахован, это не аргумент. Я упомянул про это не в качестве аргумента за или против, а чтобы показать отличие. Если кто-то использует =, то будет точно так же, как сейчас. А новый оператор позволит уменьшить количество вариантов, где можно совершить ошибку.
Это абсолютно никак не уменьшает сложность перевода. Как нарисовать сову? Элементарно — ставится директива: нарисовать сову.
Есть такие проекты, это факт. Для них нужно писать код, это тоже факт. Не думайте только о себе.
Речь не о том, нужны шаблонизаторы или нет. Шаблонизаторы вещь полезная, это тоже факт.
Отсутствие шаблонизатора не означает код плохого качества.
Дело не в том, что и где можно заменить. а в том, что часто повторяется одно и то же действие, а если случайно его не повторить, то это приводит к проблемам в безопасности.
Предложите пожалуйста такой же бесконечно простой способ перевести 100500 работающих шаблонов в большом внутреннем проекте компании с PHP на Twig.
<?~ ?> и есть способ с автоматическим экранированием.
Поэтому в статье я специально обратил внимание на то, что требуется мнение людей, которые реально работают с проектами без шаблонизаторов.
Не вижу связи. Для введения неймспейсов и других нововведений были свои причины. Причины для появления такого оператора я изложил в статье. Он не уменьшает безопасность и не увеличивает длину названий в коде, как раз наоборот.
Но проблема с функцией немного шире. Как обеспечить глобальную доступность экранирующей функции в каждом файле представления? Делать дополнительный include_once / require_once при каждом рендеринге шаблона? Подключать один раз при старте приложения, независимо от того, будем мы рендерить HTML или нет? Автозагрузки функций в PHP еще нет, это пока только на стадии RFC.