Пример был не самый удачный, но теперь хочется в общем осознать ряд принципиальных моментов в реализации шаблонизатора и понять мертвые и живые ветки.
andylars 21.07.2015 16:47
1.Инициализация шаблона (каскада шаблонов).а.Последовательное присваиваниеЭто как раз случай с assign'ами в Templet.
Мы "квантовано" и асинхронно задаем значения переменных/слотов в шаблонах и только потом вызываем Render.
b.Одномоментный каскадный аргумент.Способ конфигурирования шаблона при обращении одномоментно к его рендеру, в виде мгновложенной передачи аргументов.
Хотя это и выглядит, как
"последний выдох господина ПЖ" :), на самом деле этот рендер, тоже должен делаться в конце.
А параметры к нему могут набираться через все условия выше.
Т.е. в роли assign выступают просто переменные сайта/движка, необходимые для формирования конечных параметров шаблона.
Такой параметризации пришел просто "от бедра". Поэтому я его кручу до того момента, пока не увижу что он мертвый.
Но хочется побороться подольше.
В ранних примерах показано не удачно применение, т.к. в switch[$Url] мы вызываем два разно-сконфигурированных рендера).
Плюсы: синаксическая и структурная наглядность всего собираемого и конфигурируемого шаблона - в виде каскада аргументов.
Минусы: изучаются... (есть ощущение что я поймаю синтаксические грабли, которые все изуродуют)
2.Темы/пакеты"Тема" тут тоже не ясно что понимать под темой.
Разными темами может быть просто голый набором разных конфигураций одного шаблона(пакета), или принципиально разные шаблоны(пакеты) даже если они наследованы.
Тут мысли не закончены.
Вообще, пытаюсь идти методом KISS, поэтому чувствуя один и тот же паттерн, я форсированно упрощаю.
Поэтому, например, "тему" или "пакет" вижу (пока), как просто корневой узел иерархии, по сути такой же шаблон,
в котором, в его единственный слот(слоты), вставлен начальный grid некоторо.
Т.е. разные и темы и шаблоны могут уложиться, как методы всего одного класса, одно вложено в другое,
по сути (вопрос поддержки имен я пока вынесу вообще за скобки, потому что под вопросом рабочая ли схема в принципе)
В общем, я хочу пройти путь велосипедостроения, не столько даже ради самого велосипеда, сколько, чтобы глубже понять вообще аспект шаблонизации и какие приемы удачны, а какие нет и почему.
Меня больше беспокоит то, что я использую ^вызовы и junction в параметризации, и тут хотелось бы попробовать не врюхаться в ^process,
но что-то я начинаю верить в это все меньше.
Я не понял как вы будете темы менять...
В последнем куске кода есть явные ссылки на Тему2 и Тему1.
Если тему пользователь выберет в настройках сайта, как будет выглядеть ваш main?
Ну пример был очень абстрактный, и малопрактичный, если речь идет о том, чтобы тягать в один рендер куски из разных тем.
А если под темами понимать, то что описано выше, т.е. некие именованные пред-конфигурации одного шаблона,
то выглядеть будет примерно так:
@main[]
$UsrTheme[ThemeWide]
^Tpl:[$UsrTheme][
$.Title[Наша страница]
]
@CLASS
Tpl
# в данном случае под темой сделаем, допустим, разные конфигурации одного шаблона
# например, используем один Grid, но меняем размеры шрифта
@ThemeWide[_param]
$_conf[
$.Font[large]
]
^_conf.add[$_param]
^GridCommon[$_conf]
@ThemeCozy[_param]
$_conf[
$.Font[small]
]
^_conf.add[$_param]
^GridCommon[$_conf]
@GridСommon[_param]
$_slot[
$.Font[medium]
$.Title[undefined]
]
^_slot.add[$_param]
<html>
<body>
<h1 style="font-size:$_slot.Font">$_slot.Title</h1>
</body>
</html>Меня больше беспокоит, что я использую вложенные junction и вляпаюсь в какой-нить process,
но это будет касаться момента конфигурации шаблона(пакета), тога я могу пойти по методу assign,
но вот идею, что шаблон - это пакет шаблончиков, которые есть просто методы,
и которые можно вкладывать бесконечно друг в друга, что есть нативное свойства Парсера,
хочется доиграть.
