13 521
правка
Изменения
м
Пока непонятно, нужно ли и в каком виде (идеи):
* Возможность компиляции частей шаблона («компонентов») как в HTML, так и в JS, генерирующий HTML — полезно для динамических интерфейсов. Круче всего, если бы оно умело сразу ещё и создавать экземпляр JS-объекта, инкапсулирующего данный «компонент», и само привязывало события к конкретным элементам внутри «компонента».
* Поддержка проверки формата входных данных?
* «Классо-образный» синтаксис вызова функций из шаблонов?
* «Декларативные» шаблоны, «функциональная» обработка шаблонов в противовес «процедурной»? То есть сначала разбиваем на куски, потом заменяем вычисляемые элементы. За этим стоит сырая идея — если мы будем так обрабатывать запросы в код, это даст ему возможность узнавать, какие же реально шаблону нужны данные, и вытаскивать из базы ровно их.
<blockquote>
То есть, как бы шаблоны, которые можно выполнять с любого места в любой момент. То есть либо убрать инструкцию SET, либо превратить её в по сути DEFINE :)
И тогда ещё одна концепция: «генераторы». То есть некая функция, которая может дать много ответов сразу, причём быстрее, чем давать их по одному. Но выдавать всё сразу изначально не хочется, а хочется заюзать ленивость по полной. Шаблонизатор мог бы пройтись по всему коду шаблона, собрать встреченные вызовы генераторов, смело сгруппировать их и обработать пачками.
</blockquote>
→Идеи для новой новой версии
* Наследование шаблонов.
* HTML-режим, в котором по умолчанию экранируется всё, а чтобы не экранировать или экранировать иначе, нужно специально навесить сверху нужное преобразование, что-то типа <tt>{raw(value)}</tt> или <tt>{js(value)}</tt>. Хотя возможны проблемы с, скажем, JS внутри значения параметров типа onclick.
Ни в коем случае:
* legacy-синтаксис функций {var/s}.
* Вероятно, убрать старый вариант блоков BEGIN b AT x BY y TO z (нах.. он не нужен).
Пока непонятно, нужно ли и в каком виде (идеи):
# Поддержка проверки формата входных данных?
# «Классо-образный» синтаксис вызова функций из шаблонов?
# Концепт номер раз
# Концепт номер два
=== Концепт номер раз: Декларативные шаблоны ===
Концептуальная идея: «декларативные» шаблоны и «функциональная» их обработка, в противовес «процедурной».
То есть, сначала разбиение шаблона на части (статические и вычисляемые), потом в негарантированном порядке заменяем вычисляемые элементы. За этим стоит идея — если мы будем так обрабатывать запросы в код, это даст возможность коду узнавать, какие же реально шаблону нужны данные, и вытаскивать из базы ровно их.
То есть, как бы шаблоны, которые можно выполнять с любого места в любой момент. То есть либо убрать инструкцию SET, либо превратить её в по сути DEFINE :)
И сразу концепция, которая бы дала возможность коду «узнавать»: «генераторы». Генератор — это некая функция, которая может дать много ответов сразу, причём быстрее, чем если каждый из них давать по одному. Но конкретный набор нужных данных неизвестен, генерировать и выводить в шаблон всё сразу не хочется, а хочется заюзать ленивость по полной. Шаблонизатор мог бы пройтись по всему коду шаблона, собрать встреченные вызовы генераторов, смело сгруппировать их и обработать пачками.
Но до этого вряд ли дело дойдёт.
=== Концепт номер два: HTML-компоненты ===
Мысль: классический подход к шаблонизации не совсем удобен для всё чаще и чаще необходимых динамических интерфейсов, которые с одной стороны должны выводиться через HTML, а с другой — уметь меняться через JS. При обычном подходе логику зачастую приходится дублировать, а иногда и вставлять довольно некрасивые подпорки.
Соответственно, идея: возможность компиляции частей шаблона («компонентов») как в HTML, так и в JS, генерирующий HTML. Круче всего, если бы оно умело само:
* Создавать экземпляр JS-объекта, инкапсулирующего данный «компонент»
* Автоматически цеплять этот объект к уже выведенному HTML-коду
* Автоматически привязывать события к конкретным элементам внутри «компонента»
* Обновлять DOM дерево не целиком (innerHTML), а по частям, конкретные элементы
* Автоматически обновлять представление компонента при изменении полей JS-объекта
*: Это возможно, так как шаблонизатор в курсе (большинства) зависимостей частей представления от конкретных элементов данных
* Уметь «переключать» представление на новый объект, также меняя только его части
== Идеи (от прошлой версии) ==
