По-моему нужно стараться избегать работ, где нужно всего лишь поддерживать некий старый код, который не будет развиваться.
А так непонятная ситуация, зачем работодателю думать какой там я PHP буду использовать для проекта, обычно работодателя интересует лишь сколько денег необходимо на сервера.
Но все-таки вопросы странные, заставляют задуматься об адекватности работодателя.
Я бы из принципа ответил что-то вроде: «не помню, ибо не использую/никогда так не делаю/var_dump() „
и, если после этого этот работодатель мной не заинтересуется — я точно не буду расстроен.
Я лишь говорю о категоричности и максимализме ваших заявлений.
>>это значит что он сломан и так не должно быть
Нет не сломан, он такой какой есть, он так задумывался. Хотите по другому делайте по другому, но не надо всем это внушать.
>>И это плохо, потому что программист будет постоянно забывать
Категоричное постоянно, повторюсь если постоянно забывать — ему надо чем-то другим заняться.
>>В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо
>>вырезать не все теги, где-то надо вообще в JS.
Вот-вот, он уверенно постоянно не думает, ведь экранируется же. А раз еще и склонен постоянно забывать что-то — то точно в частном случае накосячит. А это уже даже хуже, чем если бы он везде косячил — заметить труднее. Так что нифига не панацея.
Повторюсь — я не считаю ваш подход с экранированием по умолчанию плохим, делайте как нравится, только не надо говорить категоричное «сломан, не должно быть». Автоматическое экранирование и тд и тп — не серебряная пуля, уж лучше подумать об автоматическом тестировании.
>>Если по умолчанию ничего не экранируется, это не значит, что просто «его сложнее использовать», это значит что он сломан и так не должно быть и
>>стоит подумать о том чтобы перейти на нормальный шаблонизатор, который экранирует.
Это очень спорно, во-первых экранировать разное нужно по разному, во-вторых не нужно забывать что бывает не только html
>>И это плохо, потому что программист будет постоянно забывать где надо вызывать эскейп, а где не надо.
Программист который постоянно что-то забывает, от чего окружающие страдают, по-моему совсем не программист и ему лучше пойти заняться чем-нибудь другим.
У нас проблема с непониманием терминов друг друга.
>>Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех.
>>Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения,
Я имею ввиду вариант когда архитектуры нет вообще, т.е. берется plain PHP и просто тупо пишется нечто, когда еще и трудно понять где шаблон где нет шаблона. Ну по-моему недостойный вариант рассмотрения.
>>Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно
>>для пользователя заменить все объекты на прокси, как это делали в symfony1.
Получается вы вот выше написали редко, теперь пишете немного другое.
Я же имею ввиду, что по сути разницы сейчас между обычными smarty,twig,«plain-php шаблонизаторами» особо нет.
Просто какие-то ставят некие рамки «smarty, twig» а какие-то нет, но базовый функционал — экранирование и т.д. он есть везде, где-то просто его сложнее использовать.
>>Очень редко PHP-шаблонизатор умеет автоматически экранировать выводимые строки
Это просто какая-то непонятная немного фраза.
>>Очень редко plain-PHP умеет автоматически экранировать выводимые строки
Ну так логично вроде бы, зачем язык будет делать что-то что нам может быть и не нужно.
>>Очень редко известный PHP-шаблонизатор(который выделен как отдельный проект) умеет автоматически экранировать выводимые строки
Ну так не правда, все умеют, ну или почти все.
Если речь идет вообще о мешанине хтмл и кода — там я думаю отсутствие автоматического экранирования на общем фоне не проблема даже.
Тут нужно определится что такое «обычный PHP»
Если у нас MVC или хотя бы логика отображения просто отделена — то по сути некоторую часть кода можно обозвать шаблонизатором.
И тут уже будет так как захочет разработчик — рамок нет. А если разработчик грамотный, то получится все может очень даже неплохо.
Тут дело не в удобстве.
Дело в том, что в других языках этот шаблонизатор используется и привычен, кто-то для кого он привычен будет его и в PHP использовать.
Вопрос только зачем люди из других языков приходят в PHP и тащат всякое.
По-моему это зло, поддержка проекта при смене разработчиков сильно усложнится и будет дороже, по сравнению с привычными для PHP инструментами, т.к. людей с большим опытом в jade, я думаю не сильно много.
Автор скорее всего долгое время работал либо один, либо в очень небольшой команде, когда-то он или кто-то другой из его команды придумал нечто, это нечто работает и все к нему привыкли. И это нечто кажется неоспоримо правильным, т.к. используется постоянно.
Но автор показал это на хабре и для многих это решение уже спорно, поэтому и возникла некоторая дискуссия.
Автор не понимает только одного, все будет хорошо, пока он не попадет в большую организацию где используют общепринятые стандарты, либо, что хуже, в другую организацию где тоже придумали свои, но другие, стандарты.
А с бабушкиным и т.д. ну абсолютно не корректное сравнение.
Чем будет принципиально отличаться container от cl_container? При этом, как вы понимаете вместо «container» может быть любое другое слово или слова.
>>Потому что есть разного рода расширения, плагины и т.п., где НЕ НАДО заменять и обфусцировать имена классов и идентификаторов.
А зачем их вообще обфусцировать? Экономия трафика? С этим просто сжатие справится лучше.
Собственно совершенно непонятно что вы вообще там делаете, почему не используете стандартные инструменты, по сжатию, минимизации, объединению файлов. Со стороны сейчас кажется, что вы решаете какие-то надуманные проблемы.
Чтобы объяснить, почему мне нравится использовать # приведу пример:
Представим себе сложную форму с некоторым количеством разных кнопочек, инпутов и т.д.
Некий дизайнер интерфейсов отрисовал ее, задумываясь об удобстве пользователя.
В результате у нас куча разных отступов, разные высоты элементов и тд.
Если мы используем для всего классы. у нас будет примерно как-то так:
Заметьте разницу между вашим и моим сообщением — вы категорично указываете «Все стараются», я лишь не соглашаюсь «Не все».
>>И постоянно нужно помнить о весе селекторов, не так ли?
Лично я постоянно помню — это не сложно и меня не напрягает, если вы не хотите — не помните.
>>В HTML нет точек и решёток перед классом и идентификатором соответственно.
>>К тому же, классов может быть указано несколько через пробел.
Это какой у вас такой HTML в котором такое нужно?
В нашем обычном как бы и так все понятно:
<div class="block" id="container"></div>
>>Цитата из моего топика:
>>Кстати, такой код легче прогнать через сжатие и обфускацию. Причём, не надо никаких анализаторов – ищи регуляркой по префиксам
>>и сжимай. Собственно, поэтому и используются разные префиксы для идентификаторов и классов.
Уж лучше имхо считать таким специальным сленгом.
А так непонятная ситуация, зачем работодателю думать какой там я PHP буду использовать для проекта, обычно работодателя интересует лишь сколько денег необходимо на сервера.
Я бы из принципа ответил что-то вроде: «не помню, ибо не использую/никогда так не делаю/var_dump() „
и, если после этого этот работодатель мной не заинтересуется — я точно не буду расстроен.
>> перейти на нормальный шаблонизатор,
Я имел ввиду что вот эти категоричные заявления спорны.
>>это значит что он сломан и так не должно быть
Нет не сломан, он такой какой есть, он так задумывался. Хотите по другому делайте по другому, но не надо всем это внушать.
>>И это плохо, потому что программист будет постоянно забывать
Категоричное постоянно, повторюсь если постоянно забывать — ему надо чем-то другим заняться.
>>В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо
>>вырезать не все теги, где-то надо вообще в JS.
Вот-вот, он уверенно постоянно не думает, ведь экранируется же. А раз еще и склонен постоянно забывать что-то — то точно в частном случае накосячит. А это уже даже хуже, чем если бы он везде косячил — заметить труднее. Так что нифига не панацея.
Повторюсь — я не считаю ваш подход с экранированием по умолчанию плохим, делайте как нравится, только не надо говорить категоричное «сломан, не должно быть». Автоматическое экранирование и тд и тп — не серебряная пуля, уж лучше подумать об автоматическом тестировании.
>>стоит подумать о том чтобы перейти на нормальный шаблонизатор, который экранирует.
Это очень спорно, во-первых экранировать разное нужно по разному, во-вторых не нужно забывать что бывает не только html
>>И это плохо, потому что программист будет постоянно забывать где надо вызывать эскейп, а где не надо.
Программист который постоянно что-то забывает, от чего окружающие страдают, по-моему совсем не программист и ему лучше пойти заняться чем-нибудь другим.
>>Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех.
>>Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения,
Я имею ввиду вариант когда архитектуры нет вообще, т.е. берется plain PHP и просто тупо пишется нечто, когда еще и трудно понять где шаблон где нет шаблона. Ну по-моему недостойный вариант рассмотрения.
>>Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно
>>для пользователя заменить все объекты на прокси, как это делали в symfony1.
Получается вы вот выше написали редко, теперь пишете немного другое.
Я же имею ввиду, что по сути разницы сейчас между обычными smarty,twig,«plain-php шаблонизаторами» особо нет.
Просто какие-то ставят некие рамки «smarty, twig» а какие-то нет, но базовый функционал — экранирование и т.д. он есть везде, где-то просто его сложнее использовать.
Это просто какая-то непонятная немного фраза.
>>Очень редко plain-PHP умеет автоматически экранировать выводимые строки
Ну так логично вроде бы, зачем язык будет делать что-то что нам может быть и не нужно.
>>Очень редко известный PHP-шаблонизатор(который выделен как отдельный проект) умеет автоматически экранировать выводимые строки
Ну так не правда, все умеют, ну или почти все.
Если речь идет вообще о мешанине хтмл и кода — там я думаю отсутствие автоматического экранирования на общем фоне не проблема даже.
С экранированием — это вообще вопрос одного метода короткого, по сути.
При этом разница между Smarty, Twig и JadePHP сильно много больше чем между «обычным PHP» и Smarty,Twig.
Если у нас MVC или хотя бы логика отображения просто отделена — то по сути некоторую часть кода можно обозвать шаблонизатором.
И тут уже будет так как захочет разработчик — рамок нет. А если разработчик грамотный, то получится все может очень даже неплохо.
Jade в этом плане не приносит ничего нового.
Если вы имеете ввиду plain PHP, хтмл вперемешку с кодом по всему проекту, то слово «редко» у вас лишнее.
Вы не пользуетесь IDE?
Дело в том, что в других языках этот шаблонизатор используется и привычен, кто-то для кого он привычен будет его и в PHP использовать.
Вопрос только зачем люди из других языков приходят в PHP и тащат всякое.
По-моему это зло, поддержка проекта при смене разработчиков сильно усложнится и будет дороже, по сравнению с привычными для PHP инструментами, т.к. людей с большим опытом в jade, я думаю не сильно много.
Но автор показал это на хабре и для многих это решение уже спорно, поэтому и возникла некоторая дискуссия.
Автор не понимает только одного, все будет хорошо, пока он не попадет в большую организацию где используют общепринятые стандарты, либо, что хуже, в другую организацию где тоже придумали свои, но другие, стандарты.
А с бабушкиным и т.д. ну абсолютно не корректное сравнение.
>>Потому что есть разного рода расширения, плагины и т.п., где НЕ НАДО заменять и обфусцировать имена классов и идентификаторов.
А зачем их вообще обфусцировать? Экономия трафика? С этим просто сжатие справится лучше.
Собственно совершенно непонятно что вы вообще там делаете, почему не используете стандартные инструменты, по сжатию, минимизации, объединению файлов. Со стороны сейчас кажется, что вы решаете какие-то надуманные проблемы.
Представим себе сложную форму с некоторым количеством разных кнопочек, инпутов и т.д.
Некий дизайнер интерфейсов отрисовал ее, задумываясь об удобстве пользователя.
В результате у нас куча разных отступов, разные высоты элементов и тд.
Если мы используем для всего классы. у нас будет примерно как-то так:
Человек который потом придет и захочет кнопочку сдвинуть, должен будет проверить а точно ли нигде «button_check» не используется.
>>И постоянно нужно помнить о весе селекторов, не так ли?
Лично я постоянно помню — это не сложно и меня не напрягает, если вы не хотите — не помните.
>>К тому же, классов может быть указано несколько через пробел.
Это какой у вас такой HTML в котором такое нужно?
В нашем обычном как бы и так все понятно:
>>Цитата из моего топика:
>>Кстати, такой код легче прогнать через сжатие и обфускацию. Причём, не надо никаких анализаторов – ищи регуляркой по префиксам
>>и сжимай. Собственно, поэтому и используются разные префиксы для идентификаторов и классов.
Не ясно почему легче.