Есть функция i18n, написанная на js и экспортированная в yate, она подставляет локализационные строки и где нужно обрабатывает исключения. В дев окружении она всегда работает и грузится один и тот же файл для всех локалей, для продакшена она заменяется (с помощью js-парсера) сразу на нужную строку или на нужную функцию, обрабатывающую исключение с захардкоженным набором строк. Таким образом в продакшене всегда лежит набор файлов, где для каждой локали свой файл.
1) то, что XSL впервые реализован в IE не отменяет той проблемы, что реализация во всех остальных браузерах от него отличается
2) возможно починили в свежих версиях оперы, но проблема точно есть в Opera 9.64, например, приходилось всегда объявлять <xsl:template name="null"/>, иначе самый первый <xsl:call-template> мог не отработать
3) например <xsl:template match="some[foo = bar][0]">
4) если в шаблоне есть <img src="..." onload="..." />, то эта картинка загрузится при чтении шаблона, ещё и onload может вызваться, проблема в том, что картинка грузится, а переменные в src не интерполируются, в итоге 404
5) все браузеры просят <xsl:output method="html"/>, а в хроме такой output работает не всегда и для него приходится генерить отделные шаблоны с <xsl:output method="xml"/>
6) такое мнение может пропасть, если почитать скомпилированный yate-шаблон, там всё достаточно понятно и логично, понятные имена функций, комментарии, у нас проблем с этим не возникало
7) очень спорный момент — это передавать с сервера дату сразу в 20 локалях и в индивидуальном формате для каждой локали, лучше передать timestamp и из него сделать правильный вывод при отрисовке view
8) у E4X не самая богатая документация и синтаксис не самый очевидный, он то «около-xpath», то js + он depricated + он только в SpiderMonkey + да, он медленный
9) да, yate автоматически экранирует данные, про JSON не совсем понял вопрос, но вроде он тоже экранируется
10) время трансформации — это время за которое из JSON с помощью скомпилированного шаблона получается строка с HTML, которая затем достаточно быстро вставляется в DOM с помощью innerHTML, script evaluation time для скомпилированного шаблона не учитывается, так как выполняется только один раз при загрузке шаблона и, например, профайлер оперы говорит, что уходит на это 2-3мс
11) в yate скоро появится генерация JSON, это не совсем многопроходная трансформация, но тоже весьма удобно, аналог exsl:node-set
Да, можно запускать на сервере, только nodejs, на языки, отличне от JavaScript транслировать компилятор не планируется.
Остальные вопросы скорее про используемый фреймворк, а не про шаблонизатор, не думаю, что шаблонизатору нужны все эти функции, так что нет, пока не планируется.
насколько я понял, для таких случаев работает последний абзац поста:
«А владельцев социальных сетей и других сервисов, у пользователей которых есть аватары, мы приглашаем вступить в наш союз. Пишите на адрес support@mail.yandex.ru»
видимо остаётся только даблкликнуть по имени, там-то уже ничего не помешает скопировать адрес, путь, конечно, не самый быстрый, но надёжный и проверенный временем)
Сколько времени заняла разработка?
2) возможно починили в свежих версиях оперы, но проблема точно есть в Opera 9.64, например, приходилось всегда объявлять
<xsl:template name="null"/>
, иначе самый первый<xsl:call-template>
мог не отработать3) например
<xsl:template match="some[foo = bar][0]">
4) если в шаблоне есть
<img src="..." onload="..." />
, то эта картинка загрузится при чтении шаблона, ещё и onload может вызваться, проблема в том, что картинка грузится, а переменные в src не интерполируются, в итоге 4045) все браузеры просят
<xsl:output method="html"/>
, а в хроме такой output работает не всегда и для него приходится генерить отделные шаблоны с<xsl:output method="xml"/>
6) такое мнение может пропасть, если почитать скомпилированный yate-шаблон, там всё достаточно понятно и логично, понятные имена функций, комментарии, у нас проблем с этим не возникало
7) очень спорный момент — это передавать с сервера дату сразу в 20 локалях и в индивидуальном формате для каждой локали, лучше передать timestamp и из него сделать правильный вывод при отрисовке view
8) у E4X не самая богатая документация и синтаксис не самый очевидный, он то «около-xpath», то js + он depricated + он только в SpiderMonkey + да, он медленный
9) да, yate автоматически экранирует данные, про JSON не совсем понял вопрос, но вроде он тоже экранируется
10) время трансформации — это время за которое из JSON с помощью скомпилированного шаблона получается строка с HTML, которая затем достаточно быстро вставляется в DOM с помощью innerHTML, script evaluation time для скомпилированного шаблона не учитывается, так как выполняется только один раз при загрузке шаблона и, например, профайлер оперы говорит, что уходит на это 2-3мс
11) в yate скоро появится генерация JSON, это не совсем многопроходная трансформация, но тоже весьма удобно, аналог
exsl:node-set
Остальные вопросы скорее про используемый фреймворк, а не про шаблонизатор, не думаю, что шаблонизатору нужны все эти функции, так что нет, пока не планируется.
Ничего не мешает использовать компилированные шаблоны на сервере и отправлять на клиент сразу готовый HTML.
Компиляции на клиенте пока не предусмотрено, но так как компилятор тоже написан на JavaScript, то вполне возможно, что он будет портирован на клиент.
фаербаг — не аргумент, он используется только в процессе разработки
точных сроков не скажу, но ждать, определённо, стоит
«А владельцев социальных сетей и других сервисов, у пользователей которых есть аватары, мы приглашаем вступить в наш союз. Пишите на адрес support@mail.yandex.ru»
но всё ещё остаётся возможность увидеть портрет собеседника на странице письма
да и из пришедшего письма со временем станет проще вытаскивать адрес.