Добрый день.
Нужен Template engine для java, не заточенный для WEB.
Нужен для формирования сообщений по различным каналам (СМС, E-mail, соц. сети и т.п.)

Движок должен поддерживать арифметические операции, форматирование (числа, даты), вложенные шаблоны, загрузчик шаблонов из произвольного хранилища (не только файлы). Также ветвления, работу со списками (массивами). Но, в принципе, готов рассмотреть и легковесный, типа Mustache.

Но самое основное требование - движок должен уметь определить по шаблону (включая вложенные шаблоны) список переменных, которые нужны для формирования Data Model. Есть ветвление, то надо собрать переменные по всем веткам (то есть все, что есть в шаблоне).

Уже посмотрел FreeMarker, Velocity, Mustache ... но, увы, ни один из них не позволяет получить список переменных на этапе разбора шаблона. Они все работают так: уже на этапе шаблонизации, когда известна DataModel, если в шаблоне встретилась переменная X - вызвали DataModel.get(X), то есть в порядке объявления переменных в шаблоне.
Мне это не подходит, у меня сама DataModel должна быть подготовлена на основе переменных, содержащихся в шаблоне.

Partisan M,

Поправлю утверждение:

FreeMarker, как и все остальные, парсит шаблон, стоит дерево токенов, только извлечь оттуда переменные шаблона не получится (в общем случае).

Затем, на этапе заполнения шаблона он запрашивает значения переменных из map (DataModel). Вот здесь можно их отлавливать, но это будет происходить:
- не на этапе парсинга
- в порядке объявления переменных в шаблоне
- при наличии ветвлений, запрошены будут не все переменные

Usman,

нужно что-то для Java, template engine вроде для этого и предназначен. Берем параметризованный шаблон, парсим его, внедряем значения переменных. дело за малым - получить список этих самых переменных из шаблона :)

Usman,

шаблон в виде кода ? не хотелось бы.

и я не понял, как предлагается решить обозначенную мной проблему: получить список этих самых переменных из шаблона ?

mayton,

я вроде по-русски написал, что ищу template engine, удовлетворяющий некоторым критериям.

BlazkowiczНа stackoverflow есть пример как рефлексией из Freemarker-а вытягивают переменные. Если рефлексией не хочется, то не грех и дописать API в Opensource либу.

вчера разбирался с этим. Если вкратце - то это не вариант.
По вложенным шаблонам рефлексией ничего не вытянешь, на этапе парсинга они не анализируются.
Ну и там не только рефлексия, там еще знание о названиях кучи внутренних классов требуется. У разных классов разные поля, из которых нужно рефлексией тянуть инфу. В примере обошлись несколькими - а на самом деле их там десятки (все это надо в switch прописать).

Даже если все это довести до ума (то есть повторить снаружи знание внутренностей FreeMarker), то с выходом каждой новой версии все это надо заново тестировать на предмет обратной совместимости и на предмет наличия чего то нового. Нет, это не рабочий вариант.

Дописать в либу - ну тут во время упирается. Да и не факт, что это удастся пропихнуть. Пока надо посмотреть, что есть на рынке, смотрю потихоньку, в фоновом режиме.

scf,

- шаблоны уже реализованы в упрощенном виде и работают в проме. Хотелось бы сохранить совместимость.
- любой код - это возможность сделать что-то нежелательное, умышленно или нет. То есть это может быть и небезопасно, и с точки зрения производительности - неоптимально. Зачем давать пользователю такую возможность ? Пока есть возможность без этого обойтись, надо обходиться, имхо

scf,

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

Usman,

на вход шаблонизатора надо передать именно те значения, которые есть в шаблоне, в этом вся фишка.

Usman,

тут, наверное, какое то недопонимание, только я не пойму, где именно.

на вход шаблонизатора передается и шаблон, и значения тех переменных, которые есть в шаблоне. эти значения нужно получить (это - отдельный алгоритм, который требует оптимизации), но для этого надо сперва извлечь названия переменных из шаблона.

забыл никНу у вас какая-то специфическая задача, нетипичная для шаблонизаторов. Не настаиваю, но возможно все-таки вы уперлись в свою реализацию и не видите как сделать иначе?
В теории шаблонизатору на вход подается файл с плейсхолдерами и некий контекст или модель, из которой можно вытянуть все значения плейсхолдеров. Вам же все value нужны на момент начала парсинга.. Зачем? По идее изменить шаблон вы будете не в состоянии, раз вы уже начали вычитку шаблона и вам нужны все переменные ЭТОГО шаблона. В чем профит? Единственное что я могу предположить, что получение данных из контекста тяжелое, и вы хотите получить все значения махом а потом в шаблонизаторе пробежаться без задержек. Но так ли страшен лукап значений из контекста?

Прошу прощения если нафантазировал :) Просто хотелось бы понять исток задачи, сам неоднократно оказывался в ситуации когда замыленный взгляд не позволял увидеть тривиальную альтернативу

В целом правильно нафантазировали -)
получение значений происходит путем взаимодействия с другими сервисами. Все сразу вообще нельзя получить. Зная параметры заранее, можно составить оптимальный план получения значений параметров, минимизировав количество обращений по сети. Это важно. А сами параметры при этом зависимые. В общем, это отдельная задача оптимизации.

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

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
Тут вообще дерево вариантов имен получается.

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

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