UsmanТак это ж placeholder'ы. Их можно вытащить регуляркой.
Они обычно обозначаются примерно таким образом: ${<parameter-name>}

это сейчас вытаскиваю регуляркой, потому что шаблон примитивный. а когда добавятся вложенные шаблоны, циклы, временные переменные, ветвления, арифметика, форматирование и т.д, и .т.п, то не вытащить уже

UsmanLVAто не вытащить ужепри желании можно вытащить все .

возможно, хотя и не уверен, что все.
это как с рефлексией в FreeMarker. Надо снаружи описать (повторить в каком то смысле) то, что уже сделано внутри. Грамматика это, или тайное знание о названиях приватных классов и полей, которые можно достать рефлексией. При любом изменении версии это все может перестать работать. И все это надо покрывать тестами, а ведь сам шаблонизатор уже протестирован - хочется в это верить :)

Поэтому, естественно, ищется шаблонизатор, который может эту простую задачу (для него, ведь он умеет парсить свои шаблоны!) решить "из коробки".

Usmanкоторая не относится к теме Template Engine

так я об этом и не говорю

scfПохоже на кейс для GraphQL. Но поскольку это достаточно новая штука, можно проще: Шаблон получает Map<String, String> - это параметры. Сначала пишем свою реализацию Map, которая сохраняет ключи, переданные в get(), и всегда возвращает пустую строку. Потом вызываем шаблон, передав ему эту Map. Результат работы шаблона выкидываем, но набор ключей, которые использовались в этом шаблоне, у нас теперь есть. Получаем значения для этих ключей и вызываем шаблон еще раз - теперь с настоящими данными.

Этот подход можно расширить и на модель с вложенными объектами.

так нельзя, потому что есть ветвления. а сразу по всем веткам пройтись нельзя

scf,

я в первом посте говорил, что в случае ветвления берем из всех веток. однако, холостой пробег шаблонизатора может не попасть даже в одну единственную

mars478,

Приходится как то извращаться именно "извне".
Но делать такое извне как раз неправильно, т.к. завязываемся на специфику конкретного шаблонизатора, которая весьма нетривиальна. А именно, приходится учитывать области видимости переменных в шаблоне, включая переменные, объявленные во внутренних шаблонах.

Например, мы можем объявить (через директиву #set) переменную X, и в этом же шаблоне есть ее использование в виде плэйсхолдера ${X}. Является ли X переменной шаблона ? Если она в области видимости объявленной директивы set, то не является, а если за ее пределами, то является. Можем также объявить переменную цикла X, которая живет только внутри цикла.

А когда все это касается еще и вложенных шаблонов, то все еще больше усложняется.
Например, шаблон T1 требует переменную A и делает импорт шаблона T2
Шаблон T2 требует только переменную B.
Какие переменные понадобится передать в шаблонизатор, чтобы сформировать текст на основе шаблона T1 ? Вроде просто: A и B. Но нет. Возможно, B - это переменная цикла в шаблоне T1, или такая переменная объявлена директивой #set (тут еще важно, импорт сделан ДО объявления директивы или после).

Есть и другие фишки, например, в pebble есть возможность сделать импорт шаблона, передав ему на вход какие то переменные дополнительно.

В Mustache вообще переменную задают не абсолютным именем, а относительным:


дает несколько вариантов:
автор - name
- user.name
- user[i].name
Тут вообще дерево вариантов имен получается.

Наверняка, есть и другие грабли, на которые я еще не наступил.

Ну а в общем случае задача вообще нерешаема, т.к. имя вложенного шаблона в некоторых шаблонизаторах может вычисляться динамически, через плейсхолдеры, но если отбросить такой вариант, то шаблонизатор, безусловно мог бы решить такую задачу изнутри.