Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
поддерживаю автора. поставил бы плюс, но кармы нет =(
суть в том, что если посмотреть на развитие какого-то продукта/услуги во времени, то всегда происходит момент качественного перехода на новый уровень. конечно, не без репресий, но всем все равно не угодишь. )
в итоге произойдет снижение количества шаблонизаторов и можно надеяться на повышение качества, учитывая то, что вместе с внедрением стандартов увеличивается конкуренция.
я б примкнул к обществу минимум наблюдателем.
суть в том, что если посмотреть на развитие какого-то продукта/услуги во времени, то всегда происходит момент качественного перехода на новый уровень. конечно, не без репресий, но всем все равно не угодишь. )
в итоге произойдет снижение количества шаблонизаторов и можно надеяться на повышение качества, учитывая то, что вместе с внедрением стандартов увеличивается конкуренция.
я б примкнул к обществу минимум наблюдателем.
А ещё у разных языков синтаксис разный.
А ещё — люди на разных языках разговаривают.
А ещё — есть разные браузеры и операционные системы.
И что?
А ещё — люди на разных языках разговаривают.
А ещё — есть разные браузеры и операционные системы.
И что?
Да замечательно просто всё! я всем доволен и счастлив что есть такие отзывчивые люди, готовые к конструктивному разговору.
Вот вам пример.
Если вы проследите тематику последних хабратопиков в текущем разделе, то вы бы наверняка заметили там тематику «объединить шаблоны на клиентской и серверной стороне для javascript». Так вот в этом вопросе всё хорошо на этапе теории. Как только вы начнете что-то реализовывать, то пред вами как стеной встанет вопрос: а под какой из серверных шаблонизаторов подстраиваться? Под все? Под самый популярный? Под самый популярный среди определенного языка программирования? Понимаете к чему клоню?
Стремиться к лучшему нужно, и добрее быть.
Вот вам пример.
Если вы проследите тематику последних хабратопиков в текущем разделе, то вы бы наверняка заметили там тематику «объединить шаблоны на клиентской и серверной стороне для javascript». Так вот в этом вопросе всё хорошо на этапе теории. Как только вы начнете что-то реализовывать, то пред вами как стеной встанет вопрос: а под какой из серверных шаблонизаторов подстраиваться? Под все? Под самый популярный? Под самый популярный среди определенного языка программирования? Понимаете к чему клоню?
Стремиться к лучшему нужно, и добрее быть.
Я понимаю, что вы клоните к тому, что кто-то придумает какие-то стандарты и потом будут настаивать, чтобы все подстраивались под эту гребенку. Т.е. вы предлагаете указывать другим людям, как им работать.
Вы не призывайте кого-то что-то писать, а потом всех обязывать этому следовать — вы возьмите и сами напишите шаблонизаторы, для сервер-сайда и клиент-сайда, и чтобы синтаксисы у них были одинаковые. И потом представьте это сообществу.
Вы не призывайте кого-то что-то писать, а потом всех обязывать этому следовать — вы возьмите и сами напишите шаблонизаторы, для сервер-сайда и клиент-сайда, и чтобы синтаксисы у них были одинаковые. И потом представьте это сообществу.
Почему сразу указывать? Назовем это рекомендациями. От того что кто-то чему то не следует — никто не умирает, все спокойно живут. Так уж повелось что общество всегда живет по каким то общепринятым нормам, которые вырабатывались не одним человеком и не один день. Это вы понимаете?
Сам я уже написал шаблонизатор под свои требования, который как раз и сервер-сайд и клиент-сайд. Пример реализации клиентской части вы можете найти уже сейчас. Какова целесообразность выкатывать на показ очередной шаблонизатор? Вам что-то доказать, что я так умею?
Как раз один человек и не должен придумывать то, что можно принять на норму. Как минимум нужно обладать запасом знаний многих языков программирования, чтобы учесть во внимание их особенности.
Сам я уже написал шаблонизатор под свои требования, который как раз и сервер-сайд и клиент-сайд. Пример реализации клиентской части вы можете найти уже сейчас. Какова целесообразность выкатывать на показ очередной шаблонизатор? Вам что-то доказать, что я так умею?
Как раз один человек и не должен придумывать то, что можно принять на норму. Как минимум нужно обладать запасом знаний многих языков программирования, чтобы учесть во внимание их особенности.
Вот именно что, зачем все языки загонять в одни рамки, пытаясь использовать от них минимум, лишь бы мочь использовать одинаковый синтаксис?
Языки потому и разные, что возможности и задачи на них возлагаются — разные.
Языки потому и разные, что возможности и задачи на них возлагаются — разные.
я вообще так понял, что загонять шаблонизаторы под стандарты в рамках одного языка.
лишь бы мочь использовать одинаковый синтаксис?
Для начала вопрос вам: «Вы правда считаете, что возможность использовать одинаковый синтаксис для шаблонов – это мелочь?
Почему вы считаете, что определенные рамки будут ограничивать возможности шаблонизатора в сравнении с шаблонизатором для определенного языка программирования? Вам просто так вот захотелось?
Потому что сферическая фича языка А может не поддерживаться языком Б. Как следствие — спецификацией придётся ограничить язык А от использования этой фичи. Вот и ограничение.
Во-первых, вы можете привести пример этой сферической фичи языка А которой нет в языке Б и без которой использование шаблона будет правда ущербным? Я не утверждаю что такой нет, но живой интерес и нежелание спотыкаться о потом воздуха возобладают.
Во-вторых, если таки моменты и правда критичны, то для этого специфичного языка А всегда можно сделать исключения, которые другими языками просто игнорировались или выкусывались. То есть если вы жили в языке Б без фичи, то будете так жить и дальше, не ощущая дискомфорта.
А общий стандарт как раз подразумевает выработать функционал, способный воспроизводиться в большинстве языков.
Во-вторых, если таки моменты и правда критичны, то для этого специфичного языка А всегда можно сделать исключения, которые другими языками просто игнорировались или выкусывались. То есть если вы жили в языке Б без фичи, то будете так жить и дальше, не ощущая дискомфорта.
А общий стандарт как раз подразумевает выработать функционал, способный воспроизводиться в большинстве языков.
1. Да легко. Вот вам пример смарти: {$var|strtoupper}. Эта фича — функция «strtoupper». В js функции с таким именем нет. Итого: придётся стандартом описать все возможные к использованию функции. Те, которые в этот список не попали — не могут быть использованы никогда (потому что иначе шаблоны не будут кросс-языковыми). Те, которые в список попали — на каждом из языков должны быть должным образом реализованы.
2. Тогда шаблоны не будут совместимыми и смысл стандарта пропадает
2. Тогда шаблоны не будут совместимыми и смысл стандарта пропадает
1. Вы не задумывались что отсутствие функции с таким именем не отменяет наличие такой функции, пусть не родной для ЯП?
Потом, с чего вы взяли что подобное использование в шаблоне вообще приемлемо? Может стоит задуматься о том, чтобы уйти от форматирования данных прямо в шаблоне? Например назначить некий обработчик, который запускается при каждой итерации в массиве. Да, момент спорный, но как раз это и надо обсудить, определить плюсы минусы, реализовать решение.
2. Они как раз будут совместимы, парсер будет решать в зависимости от ЯП какую как воспроизводить функцию.
Потом, с чего вы взяли что подобное использование в шаблоне вообще приемлемо? Может стоит задуматься о том, чтобы уйти от форматирования данных прямо в шаблоне? Например назначить некий обработчик, который запускается при каждой итерации в массиве. Да, момент спорный, но как раз это и надо обсудить, определить плюсы минусы, реализовать решение.
2. Они как раз будут совместимы, парсер будет решать в зависимости от ЯП какую как воспроизводить функцию.
1. Задумывался. Потому я и написал — что придётся переписывать все функции. Приемлемо — потому что шаблон инкапсулирует в себе логику представления. Регистр строкового литерала — это как раз логика представления.
2.
«можно сделать исключения, которые другими языками просто игнорировались или выкусывались.»
«Они как раз будут совместимы, парсер будет решать в зависимости от ЯП какую как воспроизводить функцию. „
Если часть шаблона будет игнорироваться парсером — тогда результаты работы шаблона в разных ЯП будут разные.
2.
«можно сделать исключения, которые другими языками просто игнорировались или выкусывались.»
«Они как раз будут совместимы, парсер будет решать в зависимости от ЯП какую как воспроизводить функцию. „
Если часть шаблона будет игнорироваться парсером — тогда результаты работы шаблона в разных ЯП будут разные.
Когда подобных фильтров становится много — шаблон выглядит громоздким.
Когда форматирование данных вынесено в отдельный обработчик, логика работы становится прозрачнее(тут копаем, тут поливаем, там красим)
Как говорит мой знакомый, мыслите шире
Не каждому верстальщику интересно думать о том, в каком виде показывать дату, переводить ли все в верхний регистр…
Разработку ведь ведет не всегда один человек?
Когда форматирование данных вынесено в отдельный обработчик, логика работы становится прозрачнее(тут копаем, тут поливаем, там красим)
Как говорит мой знакомый, мыслите шире
Не каждому верстальщику интересно думать о том, в каком виде показывать дату, переводить ли все в верхний регистр…
Разработку ведь ведет не всегда один человек?
Как по мне — место для логики отображения — в шаблонах. Что интересно верстальщику — нас интересовать не должно. Если вы вынесете эту логику из шаблона — тогда для каждой из реализаций, которая работает с шаблоном, придётся эту логику где-то реализовывать и хранить, более того — её поддерживать в актуальном состоянии.
И получается что, «мыслите шире» и не забывайте при незначительных изменениях внешнего вида вместо изменений в 1 месте (в шаблоне) бегать по всем сорсам и изменять.
И получается что, «мыслите шире» и не забывайте при незначительных изменениях внешнего вида вместо изменений в 1 месте (в шаблоне) бегать по всем сорсам и изменять.
Так или иначе — диалог у нас бессмысленный получается.
Я не вижу смысла стандартизировать.
Я не вижу смысла стандартизировать.
В зоопарк добавочки. Мы Apache Velocity используем:
А ещё непосредственно PHP используют как шаблонизатор :-)
#if( $foo < 10 )
<strong>Go East</strong>
#else
<strong>Go West</strong>
#end
<ul>
#foreach( $product in $allProducts )
<li>$product</li>
#end
</ul>
А ещё непосредственно PHP используют как шаблонизатор :-)
yeah! поддерживаю!
сделай wiki где-нибудь, там соберем весь зоопарк и опишем key features каждого решения.
а потом будем делать выводы и вычислять тенденции)
сделай wiki где-нибудь, там соберем весь зоопарк и опишем key features каждого решения.
а потом будем делать выводы и вычислять тенденции)
можно начать с Template engine (web)
сделать более развернутый обзор в части синтаксиса
сделать более развернутый обзор в части синтаксиса
en.wikipedia.org/wiki/Template_engine_(web)#Comparison
В Django, например, конструкцию object.method шаблон по очереди пытается интерпретировать как object.method(), object.method, object['method'], то есть налицо нехватка синтаксиса шаблона для доступа к возможностям языка. Мне кажется, именно здесь кроется самая сложная проблема — придумать синтаксис выражений, которого хватает на фичи всех языков и который будет поддерживаться всеми языками.
Я голосую за то, чтобы не забыли две возможности: изменение экранирующих символов (лучше всего в начале файла в манифесте это указывать) и условные блоки по текущему языку интерпретатора.
Я голосую за то, чтобы не забыли две возможности: изменение экранирующих символов (лучше всего в начале файла в манифесте это указывать) и условные блоки по текущему языку интерпретатора.
«нехватка синтаксиса шаблона для доступа к возможностям язык»
Это не нехватка синтаксиса, а унификация интерфейса. Верстальщику не зачем разбираться в методах, свойствах, массивах и т.д. Ему незачем имеет доступ к возможностям языка, ему даже не нужно знать его.
Весь топик имхо бред полный. Существуют разные шаблонизаторы, они решают разные или похожие задачи, у них разная скорость обработки и разное богатство синтаксиса. Где-то синтаксис примитивен и скорость работы высока, где-то он сопоставим с небольшим языком программирования.
Не говоря уж о том, что кому-то нарятся фигурные скобочки, а кому-то нравится когда теги шаблонизатора не отличимы от HTML тегов. Кому-то нравится краткие конструкции, а кто-то любит чтобы конструкции было хорошо видно и заметно.
Это не нехватка синтаксиса, а унификация интерфейса. Верстальщику не зачем разбираться в методах, свойствах, массивах и т.д. Ему незачем имеет доступ к возможностям языка, ему даже не нужно знать его.
Весь топик имхо бред полный. Существуют разные шаблонизаторы, они решают разные или похожие задачи, у них разная скорость обработки и разное богатство синтаксиса. Где-то синтаксис примитивен и скорость работы высока, где-то он сопоставим с небольшим языком программирования.
Не говоря уж о том, что кому-то нарятся фигурные скобочки, а кому-то нравится когда теги шаблонизатора не отличимы от HTML тегов. Кому-то нравится краткие конструкции, а кто-то любит чтобы конструкции было хорошо видно и заметно.
Перефразируем то, что вы сказали. Унификация синтаксиса языка С — бред полный. Какие-то программы примитивны настолько, что функции можно писать в одну строчку (синтаксис Ruby, например, для этого подходит идеально). Кому-то нравятся фигурные скобочки, кто-то с обожанием смотрит на begin и end. Поэтому у каждого должна оставаться возможность выбрать синтаксис, руководствуясь сложностью задачи и представлениями о прекрасном.
Очевидно, можно сделать в С поддержку множества разных синтаксисов. Очевидно также, что это очень сложно и неразумно. У нас ситуация похожая: мы пришли к необходимости создать единый синтаксис, чтобы одни и те же шаблоны понимались всеми языками. Улучшится переносимость кода (я имею в виду тот код, который в шаблонах), упростится визуальное восприятие незнакомого шаблона.
При этом никто не обязан пользоваться этим стандартом — альтернатив много. Кроме того, стандарт обязан быть гибким (чтобы соответствовать чувству прекрасного разных разработчикв) и расширяемым (чтобы удовлетворить возможности сложных языков программирования).
Очевидно, можно сделать в С поддержку множества разных синтаксисов. Очевидно также, что это очень сложно и неразумно. У нас ситуация похожая: мы пришли к необходимости создать единый синтаксис, чтобы одни и те же шаблоны понимались всеми языками. Улучшится переносимость кода (я имею в виду тот код, который в шаблонах), упростится визуальное восприятие незнакомого шаблона.
При этом никто не обязан пользоваться этим стандартом — альтернатив много. Кроме того, стандарт обязан быть гибким (чтобы соответствовать чувству прекрасного разных разработчикв) и расширяемым (чтобы удовлетворить возможности сложных языков программирования).
Не надо меня перефразировать.
«Унификация синтаксиса языка С — бред полный. Какие-то программы примитивны настолько, что функции можно писать в одну строчку (синтаксис Ruby, например, для этого подходит идеально).»
Да-да, очень метко. Именно поэтому синтаксис Ruby не похож на синтаксис C. Именно поэтому существуют разные языки программирования. Также как и разные шаблонизаторы.
Автор топике не предлагает сделать стандарт для одного отдельно взятого шаблонизатора, он предлагает унифицировать синтаксис всех.
«Унификация синтаксиса языка С — бред полный. Какие-то программы примитивны настолько, что функции можно писать в одну строчку (синтаксис Ruby, например, для этого подходит идеально).»
Да-да, очень метко. Именно поэтому синтаксис Ruby не похож на синтаксис C. Именно поэтому существуют разные языки программирования. Также как и разные шаблонизаторы.
Автор топике не предлагает сделать стандарт для одного отдельно взятого шаблонизатора, он предлагает унифицировать синтаксис всех.
Автор хочет «выработать что-то, что подходит всем» — в этом нет призыва уничтожить все остальные шаблонизаторы. Да и как вы себе это представляете? Даже интересно.
Убеждать вас далее в том, что необходим единый синтаксис, я не буду. Если вам он не нужен, вы им не будете пользоваться, всё просто. А будут им пользоваться, например, те, кто разрабатывает приложения с шаблонизаторами на сервере и на клиенте.
Убеждать вас далее в том, что необходим единый синтаксис, я не буду. Если вам он не нужен, вы им не будете пользоваться, всё просто. А будут им пользоваться, например, те, кто разрабатывает приложения с шаблонизаторами на сервере и на клиенте.
создание единого стиля шаблона имеет смысл, я так понимаю, только если меняется серверный язык. если ктото меняет серверный язык — то переписать шаблоны под новый шаблонизатор будет меньшей из проблем. выучить шаблонный синтаксис — пол часа, а отказываться в функциональности из за спорно необходимой универсальности синтаксиса шаблона — имхо не правильно
Идея единого императивного (как самого популярного, имхо) синтаксиса для шаблонизаторов на разных языках интересна. Но алгоритмами обработки, по-моему, ближе к концу надо заниматься. первые две вещи которые обсуждать это синтаксис и функциональность собственно шаблонов и интерфейсы взаимодействия с приложением на разных ЯП (способ задания шаблона, способ передачи данных, способ возврата отрендеренного шаблона, способ внедрения в шаблон хелперов, возможность и способ использования нативных и пользовательских функций/методов, режимы «песочницы» и т. п.).
Для wiki-разметки был похожий проект Wiki Creole.
Вам предстоит огромная работа по анализу и систематизации существующих механизмов шаблонов. Начните публиковать это в сети, лучше на английском языке. Я уверен, что желающие заниматься этим обнаружатся.
Желание-то есть?
Вам предстоит огромная работа по анализу и систематизации существующих механизмов шаблонов. Начните публиковать это в сети, лучше на английском языке. Я уверен, что желающие заниматься этим обнаружатся.
Дак вот что-что, а заниматься этим очень узким кругом людей (раз-два) точно не хочется.
Во-первых это не сильно в конечном итоге будет отличаться от того что есть.
Во-вторых, разные люди — разные мнения, что важно — много здравых идей
В-третьих, нудно постараться реализовать примеры на разных языках, а квалификация такое не позволяет. Без примеров нельзя(как и зацикливаться на них) — нужно анализировать то, что будет получаться не только в теории.
Во-первых это не сильно в конечном итоге будет отличаться от того что есть.
Во-вторых, разные люди — разные мнения, что важно — много здравых идей
В-третьих, нудно постараться реализовать примеры на разных языках, а квалификация такое не позволяет. Без примеров нельзя(как и зацикливаться на них) — нужно анализировать то, что будет получаться не только в теории.
Есть такое счастье — HAML.
haml-lang.com/
К нему ещё используют SASS и т.п. Изначально HAML для Руби (и RoR), но есть реализации парсеров шаблонов для многих популярных фреймворков на PHP. Имхо многое в будущем может оказаться за HAML хотя бы из-за удобства «меньше тегов в шаблоне». Но, конечно, это заставляет держать таблицу соответствия тегам инструкций HAML в голове.
haml-lang.com/
К нему ещё используют SASS и т.п. Изначально HAML для Руби (и RoR), но есть реализации парсеров шаблонов для многих популярных фреймворков на PHP. Имхо многое в будущем может оказаться за HAML хотя бы из-за удобства «меньше тегов в шаблоне». Но, конечно, это заставляет держать таблицу соответствия тегам инструкций HAML в голове.
Хорошим тоном и практикой в XSLT считается максимально использовать xsl:apply-templates вместо xsl:if и xsl:choose. А это — уже совершенно другой подход к написанию и понимаю шаблона
Элемент <xsl:apply-templates> сначала выбирает набор узлов с помощью выражения, заданного атрибутом select.Если этот атрибут не задан, выбираются все дочерние элементы текущего узла.Для каждого из выбранных узлов атрибут <xsl:apply-templates> указывает обработчику XSLT, что нужно найти соответствующий шаблон <xsl:template> для применения.Применимость шаблонов проверяется сравнением узла с выражением XPath, заданным в атрибуте match данного шаблона.Если соответствие найдено для нескольких шаблонов, выбирается шаблон с наивысшим приоритетом.Если несколько шаблонов имеют одинаковый приоритет, выбирается тот, который расположен в таблице стилей последним.
Если я правильно понимаю, то такой подход диктуется особенностью самой связки xml+xslt.
В случае когда шаблон будет компилироваться в нативный код языка программирования, использование конструкций if/else не имеет побочных эффектов. А если целью стоит читабельность основного шаблона, то можно применять инклуды/блоки, которые будут по выбранному набору данных вставлять уже более подробный кусок html.
А если вам нужно в зависимости от одних данных генерировать часть шаблона, используя уже другие данные? То есть проверки if / else уже не избежать.
Или я не до конца уяснил идею?
Автор, вам никто не мешает использовать тот же CT++ или XSLT с любым языком программирования. А у CT++ к тому же можно использовать различный синтаксис шаблонов, или вообще создать свой супер-мега-синтаксис, как вам это нравится.
Автор, вы занимаетесь ерундой.
Никто, поверьте, никто не будет всерьез заниматься разработкой единого стандарта синтаксиса шаблонизаторов.
Основные причины:
1) неуниверсальных стандартов потому и много, что они занимают каждый свою нишу. Они умеют мало, зато быстро и без оверхеда.
2) универсальный стандарт есть. Называется XSLT. Второй всеобъемлющий универсальный стандарт никому не нужен — это анархия. Универсальность стандарта делает его в ряде случаев неудобным. Решительно все реализации XSLT процессоров медленны по сравнению с другими нишевыми шаблонизаторами. Кроме того, спецификация языка очень сложна и найти нормального верстальщика — нетривиальная задача.
Вы верите в успех и при этом молоды, полны сил и готовы изменить мир? Отлично, встретимся здесь же через год.
Никто, поверьте, никто не будет всерьез заниматься разработкой единого стандарта синтаксиса шаблонизаторов.
Основные причины:
1) неуниверсальных стандартов потому и много, что они занимают каждый свою нишу. Они умеют мало, зато быстро и без оверхеда.
2) универсальный стандарт есть. Называется XSLT. Второй всеобъемлющий универсальный стандарт никому не нужен — это анархия. Универсальность стандарта делает его в ряде случаев неудобным. Решительно все реализации XSLT процессоров медленны по сравнению с другими нишевыми шаблонизаторами. Кроме того, спецификация языка очень сложна и найти нормального верстальщика — нетривиальная задача.
Вы верите в успех и при этом молоды, полны сил и готовы изменить мир? Отлично, встретимся здесь же через год.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандарты синтаксиса шаблонизаторов