Как обозвать такую сущность?

metatemplates ? И еще например Stub?

На ум приходит только пирамидовский scaffold, хотя там этот термин употребляется для другого. Но вроде подходит.

stub — это по сути заглушка, абстрактный объект, который сам по себе не работает, а требует подключения конкретных реализаций вместо него. По крайней мере у меня оно так обзывается :) Скажем, log_stub — это система логов, которая никуда не пишет и которую в реальных системах нужно менять на конкретный логгер.

metatemplates — и длинно и контекстно некорректно. meta-сущности — это сущности или такого же уровня, как их наследование, просто как некое обобщение или как сущность более высокого уровня, включающая в себя рассматриваемые. А у нас — наоборот, сущность мелких шаблонов является составляющей частью шаблонов.

Может, что-то типа templates brick? Уже лучше выходит, хотя всё равно не очень ещё как-то...

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

Ну вообще да. Там это параметр предварительной конфигурации приложения - «указываем мастеру создания, что хотим использовать то-то и то-то».
Кстати!

Из словаря Smirnitsky (Ru-En)
костыль
м.
1. crutch; мн. pair of crutches sg.
ходить на костылях — walk on crutches
2. (большой гвоздь) spike, drive
3. ав.:
хвостовой костыль — tail-skid

Из словаря Большой русско-латинский словарь (Ru-La)
костыль
fulcrum [i, n]; balulum [i, n]; grallae, arum, fpl

Еще есть хорошее слово brickbox.

basic templates / composite templates ?

указываем, что формирование html-кода должно использоваться с таким-то набором подстановок. Или прямо шаблонизатор сам укажет, что он использует.
Вопрос — как красиво, корректно и кратко обозвать такую сущность?

подстановок

Substitution?

former

template render strategy

Используй для нейминга пространства имен, особенно вместо составных имен. Например вместо того чтобы писать ViewTemplateRenderer, делать так: View\Template\Renderer, но когда надо, разумеется писать одним словом и возможно составным. Вообще стараться именовать так, чтобы было меньше телодвижений по проекту: закладывается сущность и уже ниже ее зависимости, а не разбросанные по всему проекту (иначе получается веселая навигация). Сущности должны как части аккорда располагаться в идеале.

Советую почитать:

http://theamiableapi.com/2012/01/16/java-api-design-checklist/ там секция naming и explain-ы по ссылкам.

В частности: http://theamiableapi.com/java-cl-section-1-2/#cl.item.1.2.5

SOLID

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

meta former

Значит, для гибкой привязки шаблонов и модулей нужна новая сущность — статический список классов и html-шаблонов, выражающих те или иные особенности шаблонов (скажем, в одном случае ящик с шапокой это два-три вложенных div, в другом — dl/dt/dd).

Diazo, Diazo и ещё раз Diazo

Diazo allows you to apply a theme contained in a static HTML web page to a dynamic website created using any server-side technology. With Diazo, you can take an HTML wireframe created by a web designer and turn it into a theme for your favourite CMS, redesign the user interface of a legacy web application without even having access to the original source code, or build a unified user experience across multiple disparate systems, all in a matter of hours, not weeks.

When using Diazo, you will work with syntax and concepts familiar from working with HTML and CSS. And by allowing you seamlessly integrate XSLT into your rule files, Diazo makes common cases simple and complex requirements possible.

partials

template
и не надо никаких новых слов выдумывать. То что из шаблона получается другой шаблон — а кто обещал что из шаблона не должен получаться шаблон другого формата?
Вот есть такой язык Haxe, который компилится в другие языки. И что, метаязык? Или язык-язык? Нет, просто ещё один язык.

А при чём тут диазосоединения? :)

В БЕМ-е у каждого модуля есть файл конфига, задающий морфинг.

PS. В итоге этой мегагибкой системой в состоянии пользоваться только яндексовские евангелисты.

Substitution?

Или, поддерживая одного из предыдущих ораторов, template substitution. Таки согласен с сохранением термина template и невыдумыванием лишних сущностей.

templates-set, templates-kit

Вопрос — как красиво, корректно и кратко обозвать такую сущность?

x

Вопрос — как красиво, корректно и кратко обозвать такую сущность?

PHP )))

при чём тут php?

template-contexts? - в том плане что это по сути декларативное описание какие контекстные данные нужны для шаблонов Еще варианты schema, layouts