Затрудняюсь ответить, поскольку с XSL практически не знаком. В CT++ компилятор и парсер отделены от виртуальной машины, а виртуальной машине требуется лишь корректный байткод, и не важно как он получен. Т. е. можно переписать компилятор, еще проще добавить функций, и можно править парсер. Так довольно просто достичь синтаксиса, подобного другому шаблонизатору сопоставимому по функциональности с CT++.
В общем то, таким образом можно выстраивать сколь угодно длинные цепочки:
CTPP->SSI->CTPP->SSI… SSI->SSI… CTPP->CTPP
и на каждом этапе у вас может быть настроено кэширование стандартными возможностями Nginx.
К 1-ому, можно еще и так сделать:
г) SSI страница с include будет формировать из пары JSON подзапросов новый JSON документ, который уже далее будет обработан CT++ шаблоном и вставлен в другую SSI страницу.
И в дополнение к (в) с цепочкой из пары nginx я загнул, можно и один использовать, делать подзапросы через http-proxy самому себе.
1) Тут нужно разобраться, зачем вы кэшируете страницу с CT++ инструкциями. В модуле находится исключительно виртуальная машина, которая выполняет байткод. В настоящий момент байткод подгружается из файла и не кэшируется. В будущих версиях байткод можно будет «доставать» откуда угодно подзапросом, а также очень эффективно кэшировать его в разделяемой памяти самого Nginx для заведомо предустановленных шаблонов.
Байткод служит лишь для преобразования JSON во что-нибудь иное текстовое. Т. е. он нужен только там, где на входе идет JSON. Вы можете сделать одним из следующих способов:
а) Отдавать (и кэшировать если вам надо) SSI страницу, в которой будут include с запросами к разным сервисам, отдающим JSON, и каждый ответ будет обрабатываться CT++ и вставлятся в SSI страницу. При этом JSON ответ этих сервисов вы можете опять же закэшировать. А временем работы виртуальной машины CT++ можно практически пренебречь (там типичные величины менее 1мс).
б) Отдавать JSON, в котором будут в том числе и инструкции SSI-include, кэшировать этот JSON, он будет преобразовываться и отдаваться SSI модулю, и далее как в 1-ом пункте.
в) (наиболее некрасивый способ) Выстроить цепочку из пары nginx серверов стоящих друг за другом, один будет кэшировать ответ другого, а другой будет преобразовывать JSON в SSI-страницу.
2) Такого вроде бы нет, не видел. Но, на самом деле, то, что вы хотите можно легко добавить, нужно лишь знание C++ и немного свободного времени. Имеет смысл написать по этому поводу автору CT++, и, быть может, он добавит либо подскажет как это делается иначе. Ну или я, если уж так это востребовано, как-нибудь найду время реализовать и пришлю патч разработчику CT++.
Один из тестов к модулю называется Matryoshka, он состоит в том, что сервер запрашивает JSON, пропускает через CT++, и на выходе получается страница с директивами SSI-include, которые обрабатываются SSI модулем и делаются несколько подзапросов, каждый из подзапросов также берет JSON, пропускает через CT++ и результат отдает SSI модулю.
Что и где на каком месте кэшировать, в общем-то вы определяете сами. Все обработчики запросов, в том числе кэш работают до модулей фильтров, коими являются мой и SSI модуль. При этом мой стоит перед SSI.
Кажется, ответил на ваш вопрос.
По поводу переменных. Совершенно точно там есть возможность установки переменной значения по умолчанию, т. е. если она не будет задана, то будет использовано это значение. Вы это имели ввиду? Если просто строго присвоить переменной некое значение в шаблоне, то в этом для самого шаблонизатора нет никакого смысла, вы с тем же успехом можете перед компиляцие прогнать шаблон через какой-нибудь скрипт, который заменит определенные вами метки на интересующее вас значение. Или я чего-то недопонял?
Поясню по разруливание запросов подобнее. У нас есть данные, данные которые кто-то запросил по протоколу http(s). Эти данные мы можем в зависимости от клиента представлять в том или ином виде, и это фактически и есть часть поцесса разруливания запросов. Приложение генерирует данные, а веб-сервер это интерфейс доступа к ним. Тут нет каких-либо «идеологических» противоречий с функций веб-сервера, который уже занимается обработкой запросов.
А на счет привязки к nginx, так единственная «привязка», это к CT++. Вы же можете его и отдельно использовать, и в качестве модуля к Python, Perl, PHP, и просто из любого языка, как вызов функции, или как вызов программы. Когда вы устанавливаете CT++ в систему, у вас помимо компилятора (ctpp2c), есть еще отдельно и интерпретатор (ctpp2i) и виртуальная машина (ctpp2vm).
CT++ отлично существовал и развивался задолго до появления модуля к nginx. =) Другое дело, что его привязка к другим языкам, зачастую не очень эффективна. Тот факт, что nginx написан на Си, позволил мне довольно легко встроить в него ctpp2 (написанный на C++) наиболее эффективным образом.
Современные сервера уже давно по возможностям конфигурирования — целые фреймфорки, уже из коробки, и занимаются фактически разруливанием запросов. В том же nginx есть даже интепретатор Perl встроенный.
Более того, забыл упомянуть еще важный момент. Путь к байткоду шаблона можно задавать не только в nginx.conf, но и передавать от бэкенда вместе с JSON, в специальном HTTP заголовке «X-Template» (название его можно настроить). Причем, если модуль не может определить путь к шаблону (нет в заголовке и не указан в nginx.conf), то шаблонизации происходить не будет, JSON будет отдаваться как есть. Так вы можете легко сделать так, что без дополнительной конфигурации у вас по одному uri будет одаваться или html или json для JavaScript нужд. В первом случае ваш бэкенд будет посылать заголовок с путем до шаблона, а во втором нет.
Но это еще не все. =) Модуль ничего не делает с заголовком Content-Type, как с ним работать — на ваше усмотрение. Так вы можете устанавливать его совершенно свободно на бэкенде, и прибавить к JSON, HTML еще и RSS ленту (ваш бэкенд установит соответсвующий заголовок и путь к соответвующему шаблону формирующему XML).
Зашел в блог Nginx, глядь там топиком ниже кто-то модуль анонсировал, который берет данные из MySQL базы и отдает в виде JSON. В связке с моим модулем этот JSON тут же может превратиться в HTML или в RSS, к примеру.
В общем то просто все. Разрабатываете шаблоны сайта с использованием CT++ синтаксиса. Он довольно простой, верстальщики должны легко освоить. Как у всех, есть переменные, ветвления, циклы. В принцыпе к компилятору этому можно прекрутить и, к примеру, Django подобный синтаксис. Тут нет каких-либо технических ограничений, просто кто-то должен этим занияться. Синтаксис сейчас примерно такой: ctpp.havoc.ru/doc/ru/ (к сожалению дока не отражает нововведения версии ct++ 2.6, с которой работает модуль).
Имея шаблоны, вы компилируете их в эффективный байт-код, происходит это достаточно быстро и просто:
$ ctpp2c 'путь/к/исходнику' 'путь/к/результату'
Собрав nginx с модулем, вы можете указать в nginx.conf в любой из секций, с помощью директивы template путь к вашему скомпилированному шаблону, и включить модуль в работу с помощью директивы ctpp2 on. С этого момента, при обращении по соответвующему локэшену сервер nginx будет ожидать данные для страницы в формате JSON от бэкенда (или просто из файла), подгружать байткод шаблона и запускать виртуальную машину, результат шаблонизации отдавать клиенту.
Более того, вы можете построить целый асинхронный контроллер, компаную данный модуль и SSI, и отдельные части html страницы у вас будут формироваться из разных шаблонов и разных запросов JSON данных из разных мест. Благодаря Nginx все это будет происходить асинхронно и параллельно, если вам нужено получить данные для страницы из двух разных мест, например, из какого-нибудь nosql базы и еще какого-то сервиса стороннего, то эти данные будут запрошены параллельно, а не последовательно, и задержки не будут суммироваться.
Я всегда включаю в редакторе кода отображение табов. И количество стрелочек (обычно так обозначается таб) глаз считает гораздо быстрее. Если включить отображение пробелов, то видать много точек, которые посчитать уже сложнее, и воспринимаются хуже.
Сдвиг не может быть равен 4 таба + пробел. Вы статью читали? Отступ делается только табами. Выравнивание пробелами.
В приведенном у Pilot34 фрагменте все три строчки внутри функции относятся к одному блоку кода, очевидно, с одинаковым отступом. Одинаковый отступ значит одинаковое число табов. И сколько бы вы не поставили размер таба, все строчки будут сохранять одинаковый отступ.
Вам в конце статьи автор даже пример привел. На одном и том же фрагменте кода изменял размер табов от 2 до 9, и ничего не поехало.
ngx-ctpp.vbart.ru/settings#template
В этом случае заголовок X-Template от бэкенда не требуется.
Также удобно пользоваться в сочетании с директивой templates_root
Если вам нужен именно подзапрос на бэкенд, то используйте SSI-include:
sysoev.ru/nginx/docs/http/ngx_http_ssi_module.html#commands
Но вообще в Nginx уже есть XSLT модуль: sysoev.ru/nginx/docs/http/ngx_http_xslt_module.html
CTPP->SSI->CTPP->SSI… SSI->SSI… CTPP->CTPP
и на каждом этапе у вас может быть настроено кэширование стандартными возможностями Nginx.
г) SSI страница с include будет формировать из пары JSON подзапросов новый JSON документ, который уже далее будет обработан CT++ шаблоном и вставлен в другую SSI страницу.
И в дополнение к (в) с цепочкой из пары nginx я загнул, можно и один использовать, делать подзапросы через http-proxy самому себе.
Байткод служит лишь для преобразования JSON во что-нибудь иное текстовое. Т. е. он нужен только там, где на входе идет JSON. Вы можете сделать одним из следующих способов:
а) Отдавать (и кэшировать если вам надо) SSI страницу, в которой будут include с запросами к разным сервисам, отдающим JSON, и каждый ответ будет обрабатываться CT++ и вставлятся в SSI страницу. При этом JSON ответ этих сервисов вы можете опять же закэшировать. А временем работы виртуальной машины CT++ можно практически пренебречь (там типичные величины менее 1мс).
б) Отдавать JSON, в котором будут в том числе и инструкции SSI-include, кэшировать этот JSON, он будет преобразовываться и отдаваться SSI модулю, и далее как в 1-ом пункте.
в) (наиболее некрасивый способ) Выстроить цепочку из пары nginx серверов стоящих друг за другом, один будет кэшировать ответ другого, а другой будет преобразовывать JSON в SSI-страницу.
2) Такого вроде бы нет, не видел. Но, на самом деле, то, что вы хотите можно легко добавить, нужно лишь знание C++ и немного свободного времени. Имеет смысл написать по этому поводу автору CT++, и, быть может, он добавит либо подскажет как это делается иначе. Ну или я, если уж так это востребовано, как-нибудь найду время реализовать и пришлю патч разработчику CT++.
Что и где на каком месте кэшировать, в общем-то вы определяете сами. Все обработчики запросов, в том числе кэш работают до модулей фильтров, коими являются мой и SSI модуль. При этом мой стоит перед SSI.
Кажется, ответил на ваш вопрос.
По поводу переменных. Совершенно точно там есть возможность установки переменной значения по умолчанию, т. е. если она не будет задана, то будет использовано это значение. Вы это имели ввиду? Если просто строго присвоить переменной некое значение в шаблоне, то в этом для самого шаблонизатора нет никакого смысла, вы с тем же успехом можете перед компиляцие прогнать шаблон через какой-нибудь скрипт, который заменит определенные вами метки на интересующее вас значение. Или я чего-то недопонял?
А на счет привязки к nginx, так единственная «привязка», это к CT++. Вы же можете его и отдельно использовать, и в качестве модуля к Python, Perl, PHP, и просто из любого языка, как вызов функции, или как вызов программы. Когда вы устанавливаете CT++ в систему, у вас помимо компилятора (ctpp2c), есть еще отдельно и интерпретатор (ctpp2i) и виртуальная машина (ctpp2vm).
CT++ отлично существовал и развивался задолго до появления модуля к nginx. =) Другое дело, что его привязка к другим языкам, зачастую не очень эффективна. Тот факт, что nginx написан на Си, позволил мне довольно легко встроить в него ctpp2 (написанный на C++) наиболее эффективным образом.
Но это еще не все. =) Модуль ничего не делает с заголовком Content-Type, как с ним работать — на ваше усмотрение. Так вы можете устанавливать его совершенно свободно на бэкенде, и прибавить к JSON, HTML еще и RSS ленту (ваш бэкенд установит соответсвующий заголовок и путь к соответвующему шаблону формирующему XML).
В общем то просто все. Разрабатываете шаблоны сайта с использованием CT++ синтаксиса. Он довольно простой, верстальщики должны легко освоить. Как у всех, есть переменные, ветвления, циклы. В принцыпе к компилятору этому можно прекрутить и, к примеру, Django подобный синтаксис. Тут нет каких-либо технических ограничений, просто кто-то должен этим занияться. Синтаксис сейчас примерно такой: ctpp.havoc.ru/doc/ru/ (к сожалению дока не отражает нововведения версии ct++ 2.6, с которой работает модуль).
Имея шаблоны, вы компилируете их в эффективный байт-код, происходит это достаточно быстро и просто:
Собрав nginx с модулем, вы можете указать в nginx.conf в любой из секций, с помощью директивы template путь к вашему скомпилированному шаблону, и включить модуль в работу с помощью директивы ctpp2 on. С этого момента, при обращении по соответвующему локэшену сервер nginx будет ожидать данные для страницы в формате JSON от бэкенда (или просто из файла), подгружать байткод шаблона и запускать виртуальную машину, результат шаблонизации отдавать клиенту.
Более того, вы можете построить целый асинхронный контроллер, компаную данный модуль и SSI, и отдельные части html страницы у вас будут формироваться из разных шаблонов и разных запросов JSON данных из разных мест. Благодаря Nginx все это будет происходить асинхронно и параллельно, если вам нужено получить данные для страницы из двух разных мест, например, из какого-нибудь nosql базы и еще какого-то сервиса стороннего, то эти данные будут запрошены параллельно, а не последовательно, и задержки не будут суммироваться.
Надеюсь выполнил вашу просьбу.
nginx [engine x] is a HTTP… server — это в первую очередь.
Реверсивный HTTP-прокси сервер из него не очень. HTTP 1.1 для бэкенда не поддерживает. Лучше уж какой-нибудь squid юзать.
В приведенном у Pilot34 фрагменте все три строчки внутри функции относятся к одному блоку кода, очевидно, с одинаковым отступом. Одинаковый отступ значит одинаковое число табов. И сколько бы вы не поставили размер таба, все строчки будут сохранять одинаковый отступ.
Вам в конце статьи автор даже пример привел. На одном и том же фрагменте кода изменял размер табов от 2 до 9, и ничего не поехало.