13 521
правка
Изменения
Новая страница: «Идеи: * Чуть более хитрую обработку пробелов ([%+ и [%- как в TT, режим для обрезания пробелов …»
Идеи:
* Чуть более хитрую обработку пробелов ([%+ и [%- как в TT, режим для обрезания пробелов в начале строки).
* Если в коде шаблона очень много инструкций — предупреждение «а не пора бы вам это перенести в код».
* Наследование шаблонов (только сначала определиться, что это вообще такое)
* HTML-режим, в котором по умолчанию экранируется всё, а чтобы не экранировать или экранировать иначе, нужно специально навесить сверху нужное преобразование, что-то типа <tt>{raw(value)}</tt> или <tt>{js(value)}</tt>. Хотя возможны проблемы с, скажем, JS внутри значения параметров типа onclick.
Ни в коем случае:
* Не добавлять фильтры :) это те же функции, только зачем-то в другом синтаксисе, некомбинируемом с другими вещами, и менее удобном.
* Не делать идентичным синтаксис вызова метода объекта и получения элемента хеша (как в TT и ещё много где).
Пока непонятно, нужно ли и в каком виде:
# Поддержка проверки формата входных данных?
# «Классо-образный» синтаксис вызова функций из шаблонов?
=== НЕ НУЖНО: декларативные шаблоны ===
Концептуальная идея: «декларативные» шаблоны и «функциональная» их обработка, в противовес «процедурной».
То есть, сначала разбиение шаблона на части (статические и вычисляемые), потом в негарантированном порядке замена вычисляемых элементов. За этим стоит идея — если мы будем так обрабатывать запросы в код, это даст возможность коду узнавать, какие же реально шаблону нужны данные, и вытаскивать из базы ровно их.
То есть, как бы шаблоны, которые можно выполнять с любого места в любой момент. То есть либо убрать инструкцию SET, либо превратить её в по сути DEFINE :)
И сразу концепция, которая бы дала возможность коду «узнавать»: «генераторы». Генератор — это некая функция, которая может дать много ответов сразу, причём быстрее, чем если каждый из них давать по одному. Но конкретный набор нужных данных неизвестен, генерировать и выводить в шаблон всё сразу не хочется, а хочется заюзать ленивость по полной. Шаблонизатор мог бы пройтись по всему коду шаблона, собрать встреченные вызовы генераторов, смело сгруппировать их и обработать пачками.
Но до этого вряд ли дело дойдёт.
=== Концепт номер два: HTML-компоненты ===
Мысль: классический подход к шаблонизации не совсем удобен для всё чаще и чаще необходимых динамических интерфейсов, которые с одной стороны должны выводиться через HTML, а с другой — уметь меняться через JS. При обычном подходе логику зачастую приходится дублировать, а иногда и вставлять довольно некрасивые подпорки.
Соответственно, идея: возможность компиляции частей шаблона («компонентов») как в HTML, так и в JS, генерирующий HTML. Круче всего, если бы оно умело само:
* Создавать экземпляр JS-объекта, инкапсулирующего данный «компонент»
* Автоматически цеплять этот объект к уже выведенному HTML-коду
* Автоматически привязывать события к конкретным элементам внутри «компонента»
* Обновлять DOM дерево не целиком (innerHTML), а по частям, конкретные элементы
* Автоматически обновлять представление компонента при изменении полей JS-объекта
*: Это возможно, так как шаблонизатор в курсе (большинства) зависимостей частей представления от конкретных элементов данных
* Уметь «переключать» представление на новый объект, также меняя только его части
=== Замечание по включениям ===
Также имеют особенность: результат этих функций подставляется даже при использовании в директивах. То есть, например, если маркеры директив <tt><nowiki><!-- --></nowiki></tt>, а подстановок <tt><nowiki>{ }</nowiki></tt>, то <tt><nowiki><!-- include(...) --></nowiki></tt> всё равно будет подставлено. Игнорировать результат нужно явно: <tt><nowiki><!-- void include(...) --></nowiki></tt>.
* Чуть более хитрую обработку пробелов ([%+ и [%- как в TT, режим для обрезания пробелов в начале строки).
* Если в коде шаблона очень много инструкций — предупреждение «а не пора бы вам это перенести в код».
* Наследование шаблонов (только сначала определиться, что это вообще такое)
* HTML-режим, в котором по умолчанию экранируется всё, а чтобы не экранировать или экранировать иначе, нужно специально навесить сверху нужное преобразование, что-то типа <tt>{raw(value)}</tt> или <tt>{js(value)}</tt>. Хотя возможны проблемы с, скажем, JS внутри значения параметров типа onclick.
Ни в коем случае:
* Не добавлять фильтры :) это те же функции, только зачем-то в другом синтаксисе, некомбинируемом с другими вещами, и менее удобном.
* Не делать идентичным синтаксис вызова метода объекта и получения элемента хеша (как в TT и ещё много где).
Пока непонятно, нужно ли и в каком виде:
# Поддержка проверки формата входных данных?
# «Классо-образный» синтаксис вызова функций из шаблонов?
=== НЕ НУЖНО: декларативные шаблоны ===
Концептуальная идея: «декларативные» шаблоны и «функциональная» их обработка, в противовес «процедурной».
То есть, сначала разбиение шаблона на части (статические и вычисляемые), потом в негарантированном порядке замена вычисляемых элементов. За этим стоит идея — если мы будем так обрабатывать запросы в код, это даст возможность коду узнавать, какие же реально шаблону нужны данные, и вытаскивать из базы ровно их.
То есть, как бы шаблоны, которые можно выполнять с любого места в любой момент. То есть либо убрать инструкцию SET, либо превратить её в по сути DEFINE :)
И сразу концепция, которая бы дала возможность коду «узнавать»: «генераторы». Генератор — это некая функция, которая может дать много ответов сразу, причём быстрее, чем если каждый из них давать по одному. Но конкретный набор нужных данных неизвестен, генерировать и выводить в шаблон всё сразу не хочется, а хочется заюзать ленивость по полной. Шаблонизатор мог бы пройтись по всему коду шаблона, собрать встреченные вызовы генераторов, смело сгруппировать их и обработать пачками.
Но до этого вряд ли дело дойдёт.
=== Концепт номер два: HTML-компоненты ===
Мысль: классический подход к шаблонизации не совсем удобен для всё чаще и чаще необходимых динамических интерфейсов, которые с одной стороны должны выводиться через HTML, а с другой — уметь меняться через JS. При обычном подходе логику зачастую приходится дублировать, а иногда и вставлять довольно некрасивые подпорки.
Соответственно, идея: возможность компиляции частей шаблона («компонентов») как в HTML, так и в JS, генерирующий HTML. Круче всего, если бы оно умело само:
* Создавать экземпляр JS-объекта, инкапсулирующего данный «компонент»
* Автоматически цеплять этот объект к уже выведенному HTML-коду
* Автоматически привязывать события к конкретным элементам внутри «компонента»
* Обновлять DOM дерево не целиком (innerHTML), а по частям, конкретные элементы
* Автоматически обновлять представление компонента при изменении полей JS-объекта
*: Это возможно, так как шаблонизатор в курсе (большинства) зависимостей частей представления от конкретных элементов данных
* Уметь «переключать» представление на новый объект, также меняя только его части
=== Замечание по включениям ===
Также имеют особенность: результат этих функций подставляется даже при использовании в директивах. То есть, например, если маркеры директив <tt><nowiki><!-- --></nowiki></tt>, а подстановок <tt><nowiki>{ }</nowiki></tt>, то <tt><nowiki><!-- include(...) --></nowiki></tt> всё равно будет подставлено. Игнорировать результат нужно явно: <tt><nowiki><!-- void include(...) --></nowiki></tt>.