Перестали ли вы слышать от новичков вопрос: «какой выбрать шаблонизатор?». Не думаю.
Единственное что можно с уверенностью сказать, что периодически некоторые решения становятся популярны в определенных кругах, но они по большей части органичение их области применения, это язык программирования. Перечислять плюсы существования каких-либо стандартов не нужно. Все понимают, «от этого хорошо будет всем». Придумать, закрепить, применить их – вот эта задача, далеко не тривиальная, но ведь решаемая.
Давайте начнем двигаться к этому.
Само собой идея ввести единый синтаксис шаблонов не нова. Как видно сейчас по многообразию существующих шаблонизаторов, синтаксис онных зависим от языка программирования.
Можно сделать вывод, что необходимо выработать что-то, что подходит всем. Отчетливо мы понимаем, что громоздкие синтаксисы не приживаются (здравствуй, xslt). Но и проявление минимализма не есть хорошо. Можно пойти по пути, когда у нас есть краткая и полная форма записи для операторов, и сделать допущение, что полная форма записи работает для всех, краткая уже для более узкого круга парсеров. То есть мы хотим получить плюшку в виде краткого синтаксиса, но готовы заплатить монету в виде отказа прямой поддержки шаблонов на языке «ххх». При этом для этого круга языков, такие шаблоны не должны быть помехой. Ну а если на захотелось перенести шаблоны на ЯП «ххх» мы должны иметь возможность оперативно пройтись по всем шаблонам и заменить краткий синтаксис на полный.
Для генерации шаблонизатору нужно скормить данные в определенном формате. Благо у нас тут более менее всё устаканилось: JSON и XML. Но, так же нужно учеть, что не всегда целесообразно подготавливать данные перед началом генерации шаблона. Бывают случаии, когда нужно формировать данные в процессе исполнения кода шаблона. Плюс сегодня некоторые шаблонизаторы предлагают возможность обработки, форматирования данных перед вставкой в шаблон. От этого так же не стоит отказываться.
Шаблонизаторы надо отличать от фрэймверков, позволяющих полностью обработать пользовательский запрос, от приёма до выдачи контента. Такая обвязка(прием, обработка, выдача) для разработки шаблонизатора — избыточна. Но, это не значит, что её не должно быть, и нужно вставлять палки в колеса разработчикам онных. Наоборот, нужно предоставить максимально простой интерфейс к использванию шаблона. Тут хочется сделать так же пометку, что в шаблонизации нуждается не только серверая часть. Применять подобный подход будет правильно и на клиентской стороне.
Парсер шаблона должен на выходе дать нам нативный код для нашего ЯП. Не нужно, чтобы при каждом обращении к шаблону нам приходилось его парсить. С этой задачей так же все справляются по разному. Кто-то игнорирует и идет в лоб, парсит при каждом обращении, кто-то генерирует код (eval-style), в каких-то ЯП есть возможность добавить метод на лету, кто-то компилирует шаблоны один раз, а затем их использует, и еще наверное есть много интересных способов. Варьируются они между простотой разработки и производительностью. А мы хотим чтобы хорошо было и тем кто использует возможность держать обработчик запросов запущенным, и от запроса к запросу только использует результирующий код шаблона, а кто-то запускает обработчик на каждый запрос, и для них вопрос времени получения исполняемого кода чувствителен. В ситуациях, когда мы компилируем шаблон, порой бывает лень внеся очередную правку запускать компилятор. Нужен механизм, позволяющий использовать пердпросмотр для нашего шаблона. тут конечно все осложняется подстановкой тестовых данных, но и это все решаемо.
Невероятно много условий.
Практика показывает, что универсальные решения частенько проигрывают узкоспециалзированным. Да, это так. Только осталось выяснить, сколько этот проигрыш будет в нашем случае? Результатом выработки стандарта хочется получить примеры реализация для каждого ЯП. Так что не думаю что будет все печально.
Вот небольшие примеры реализации операторов/тэгов в разных шаблонизаторах:
Феерично, неправда ли? Конечно, люди использующие какие-то шаблоны, уже привыкли к их особенностям, и не особо видят целесообразность менять что-то в жизни. Не хочется что-либо доказывать, кого-либо уговаривать. Не скажу что вот так сходу хватит запала просто взять все и сделать. Хочется найти людей кому это интересно. Когда работа будет идти в группе людей — то это будет хорошо мотивировать участников.
Можно говорить что это будет бесконечный процесс, или нахер никому не нужная работа. Я считаю это не так. Во-первых разбирающийся маломальски в вопросе человек в течении года-двух может реализовать свое решение, которое будет отвечать большиству его требований. Во-вторых, пока число самописных шаблонизаторов растет пропорционально количеству людей, осваивающих веб-программирование, ситуация не меняется коренным образом.
Кто-то скажет, что практиченее сегодня решить любую задачу с помощью имеющихся инструментов. Не сказать что мне всё не нравится. Нет, есть вполне достойные экземляры, но ведь это не отменяет проблемы отсуствия свода каких либо правил. Сегодня разработчики вашего шаблонизатора скажут: «а не изменить ли нам в корне подход?!», придумюат что-то несоместимое со старыми поделками. Все мы люди, рано или поздно «отходим от дел», и далеко не всегда есть кому продолжить наше дело. Тут я наверное сильно замахнулся, ведь тенденции в интернете меняются быстрее чем мы стареем, но это не отменяет сказанного.
Да, по большому счет это пока все палкой по воде. Нет никакой структуры организации работы коллектива над этой задачей, но ведь это всё дело наживное.
Коротко о главном:
Сформировать группу заинтересованных, разбирающихся в предмете, способных обсудить а затем и реализовать определенные алгоритмы обработки на разных языках программирования.
Желание то есть?
P.S. ненужно говорить, что ничегоне получится, ненужно необоснованной критики, не к чему это, не нервничайте.
Единственное что можно с уверенностью сказать, что периодически некоторые решения становятся популярны в определенных кругах, но они по большей части органичение их области применения, это язык программирования. Перечислять плюсы существования каких-либо стандартов не нужно. Все понимают, «от этого хорошо будет всем». Придумать, закрепить, применить их – вот эта задача, далеко не тривиальная, но ведь решаемая.
Давайте начнем двигаться к этому.
Само собой идея ввести единый синтаксис шаблонов не нова. Как видно сейчас по многообразию существующих шаблонизаторов, синтаксис онных зависим от языка программирования.
Можно сделать вывод, что необходимо выработать что-то, что подходит всем. Отчетливо мы понимаем, что громоздкие синтаксисы не приживаются (здравствуй, xslt). Но и проявление минимализма не есть хорошо. Можно пойти по пути, когда у нас есть краткая и полная форма записи для операторов, и сделать допущение, что полная форма записи работает для всех, краткая уже для более узкого круга парсеров. То есть мы хотим получить плюшку в виде краткого синтаксиса, но готовы заплатить монету в виде отказа прямой поддержки шаблонов на языке «ххх». При этом для этого круга языков, такие шаблоны не должны быть помехой. Ну а если на захотелось перенести шаблоны на ЯП «ххх» мы должны иметь возможность оперативно пройтись по всем шаблонам и заменить краткий синтаксис на полный.
Для генерации шаблонизатору нужно скормить данные в определенном формате. Благо у нас тут более менее всё устаканилось: JSON и XML. Но, так же нужно учеть, что не всегда целесообразно подготавливать данные перед началом генерации шаблона. Бывают случаии, когда нужно формировать данные в процессе исполнения кода шаблона. Плюс сегодня некоторые шаблонизаторы предлагают возможность обработки, форматирования данных перед вставкой в шаблон. От этого так же не стоит отказываться.
Шаблонизаторы надо отличать от фрэймверков, позволяющих полностью обработать пользовательский запрос, от приёма до выдачи контента. Такая обвязка(прием, обработка, выдача) для разработки шаблонизатора — избыточна. Но, это не значит, что её не должно быть, и нужно вставлять палки в колеса разработчикам онных. Наоборот, нужно предоставить максимально простой интерфейс к использванию шаблона. Тут хочется сделать так же пометку, что в шаблонизации нуждается не только серверая часть. Применять подобный подход будет правильно и на клиентской стороне.
Парсер шаблона должен на выходе дать нам нативный код для нашего ЯП. Не нужно, чтобы при каждом обращении к шаблону нам приходилось его парсить. С этой задачей так же все справляются по разному. Кто-то игнорирует и идет в лоб, парсит при каждом обращении, кто-то генерирует код (eval-style), в каких-то ЯП есть возможность добавить метод на лету, кто-то компилирует шаблоны один раз, а затем их использует, и еще наверное есть много интересных способов. Варьируются они между простотой разработки и производительностью. А мы хотим чтобы хорошо было и тем кто использует возможность держать обработчик запросов запущенным, и от запроса к запросу только использует результирующий код шаблона, а кто-то запускает обработчик на каждый запрос, и для них вопрос времени получения исполняемого кода чувствителен. В ситуациях, когда мы компилируем шаблон, порой бывает лень внеся очередную правку запускать компилятор. Нужен механизм, позволяющий использовать пердпросмотр для нашего шаблона. тут конечно все осложняется подстановкой тестовых данных, но и это все решаемо.
Невероятно много условий.
Практика показывает, что универсальные решения частенько проигрывают узкоспециалзированным. Да, это так. Только осталось выяснить, сколько этот проигрыш будет в нашем случае? Результатом выработки стандарта хочется получить примеры реализация для каждого ЯП. Так что не думаю что будет все печально.
Вот небольшие примеры реализации операторов/тэгов в разных шаблонизаторах:
Django:
{% if today_is_weekend %}
<p>Welcome to the weekend!</p>
{% else %}
<p>Get back to work.</p>
{% endif %}
{% for athlete in athlete_list %}
<li>{{ athlete.name }}</li>
{% endfor %}
XSLT:
<xsl:choose>
<xsl:when test="/some/node = 1">
One
</xsl:when>
<xsl:otherwise>
More.
</xsl:otherwise>
</xsl:choose>
<xsl:for-each select="/nodes/*">
Name: {./name}
</xsl:for-each>
HTML::Template:
<TMPL_IF BOOL>
Some text that is included only if BOOL is true
<TMPL_ELSE>
Some text that is included only if BOOL is false
</TMPL_IF>
<TMPL_LOOP NAME=EMPLOYEE_INFO>
Name: <TMPL_VAR NAME=NAME> <br>
Job: <TMPL_VAR NAME=JOB> <p>
</TMPL_LOOP>
Smarty
{if $name eq 'Fred'}
Welcome Sir.
{else}
Welcome, whatever you are.
{/if}
{foreach key=key item=item from=$contact}
{$key}: {$item}<br>
{$key}: {$item}<br />
{/foreach}
EJS — Embedded Javascript
<% if(question) { %>
<h2><%= author %>: <%= question %></h2>
<% } else { %>
<h2>Нет вопросов, на которые можно ответить!</h2>
<% } %>
<% for(var i=0; i<supplies.length; i++) {%>
<li><%= supplies[i] %></li>
<% } %>
* This source code was highlighted with Source Code Highlighter.Феерично, неправда ли? Конечно, люди использующие какие-то шаблоны, уже привыкли к их особенностям, и не особо видят целесообразность менять что-то в жизни. Не хочется что-либо доказывать, кого-либо уговаривать. Не скажу что вот так сходу хватит запала просто взять все и сделать. Хочется найти людей кому это интересно. Когда работа будет идти в группе людей — то это будет хорошо мотивировать участников.
Можно говорить что это будет бесконечный процесс, или нахер никому не нужная работа. Я считаю это не так. Во-первых разбирающийся маломальски в вопросе человек в течении года-двух может реализовать свое решение, которое будет отвечать большиству его требований. Во-вторых, пока число самописных шаблонизаторов растет пропорционально количеству людей, осваивающих веб-программирование, ситуация не меняется коренным образом.
Кто-то скажет, что практиченее сегодня решить любую задачу с помощью имеющихся инструментов. Не сказать что мне всё не нравится. Нет, есть вполне достойные экземляры, но ведь это не отменяет проблемы отсуствия свода каких либо правил. Сегодня разработчики вашего шаблонизатора скажут: «а не изменить ли нам в корне подход?!», придумюат что-то несоместимое со старыми поделками. Все мы люди, рано или поздно «отходим от дел», и далеко не всегда есть кому продолжить наше дело. Тут я наверное сильно замахнулся, ведь тенденции в интернете меняются быстрее чем мы стареем, но это не отменяет сказанного.
Да, по большому счет это пока все палкой по воде. Нет никакой структуры организации работы коллектива над этой задачей, но ведь это всё дело наживное.
Коротко о главном:
Сформировать группу заинтересованных, разбирающихся в предмете, способных обсудить а затем и реализовать определенные алгоритмы обработки на разных языках программирования.
Желание то есть?
P.S. ненужно говорить, что ничегоне получится, ненужно необоснованной критики, не к чему это, не нервничайте.
