Архитектура server-side приложения

[B~Vladi]

С точки зрения unit-тестирования это скорее всего тоже неудобно.

Не знаю, не пользовался. Хотя тестировать отдельные методы - как раз легко.

как?

Если тег валится с ошибкой (например, некорректное JS-выражение в атрибуте), то:
1. На объекте пространства имен шаблонизатора генерируется ошибка:

{
  message: 'ReferenceError: data is not defined',
  templatePath: 'путь к шаблону',
  TypeError: 'RenderError',
  nodeName: 'имя тега',
  line: 'номер строки',
  char: 'позиция символа, с которого начинается тег'
}

2. Тег со всем содержимым не попадает в результат.
3. Если использовать опцию конфига debug - true, на месте тега будет сгенерирован html-код:

<h3>RenderError:<br /> ReferenceError: data is not defined<br />Template: templates\page.xml<br />Node name: if<br />Line: 30<br />Char: 2</h3>

ну например, приходит запрос

Как я вижу это сейчас:
1. Запрос передается в сервис.
2. Сервис валидирует запрос и вызывает подходящий шаблон.

Есть отличие между обработкой GET- и POST-запросов?

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

вот я и говорю, что ты переносишь часть кода в язык разметки

с некоторым перекосом в сторону активности шаблона

Не вижу ничего плохого
Всё-таки есть некий предел. В PHP его нет.

А язык разметки неудобен для написания кода.

Думать надо не кодом, а конструкциями. Тогда не будет возникать таких мыслей.

есть все-таки две вещи, которых немного не хватает в mustache

Продолжай

[B~Vladi]

можно пример?

Да. Если будет решено убирать блок online-пользователей, его придется убирать и в шаблоне и в логике. В шаблоне найти легко, в логике сложнее, смотря какой там код.

Представь обычную рабочую ситуацию: пришел таск убрать некий блок. У нас сейчас достаточно скинуть задачу на верстака и он всё сделает. А так придется напрягать как верстака так и кодера. Круто? Я считаю что нет.

[x-yuri]

Если тег валится с ошибкой (например, некорректное JS-выражение в атрибуте), то:

Вообще я имел в виду скорее ошибки работы с БД, например. И что значит "На объекте пространства имен шаблонизатора генерируется ошибка:"? Ошибку надо прямо в шаблоне обрабатывать? Опять же слишком много кода в шаблонах, на мой взгляд.

Всё-таки есть некий предел. В PHP его нет.

Так дело же не в пределе. Php, несмотря на отсутствие предела, удобен как шаблонизатор. В нем код записывается в виде кода, а не в виде разметки.

Думать надо не кодом, а конструкциями. Тогда не будет возникать таких мыслей.

Это как? O.o

Продолжай

1. Не хватает or. Пример and:
   

   {{#cond1}}{{#cond2}}test{{/cond2}}{{/cond1}}
   

2. Не хватает встраивания кода в шаблон, в отдельных случаях, я таких два пока что обнаружил:
   
   
   • Автоматическое добавление времени изменения файла к url, что-то типа
     

     <link rel="stylesheet" href="{{#add_timestamp}}/css/index.css{{/add_timestamp}}">
     

   • Перевод фраз с подстановкой данных, что-то типа
     

     {{@:пользователь (?(м)отпавил)(?(ж)отпавила) Вам сообщение.}}
     

     
     И сюда надо как-то передать пользователя, м и ж.

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

Да. Если будет решено убирать блок online-пользователей, его придется убирать и в шаблоне и в логике. В шаблоне найти легко, в логике сложнее, смотря какой там код.

Представь обычную рабочую ситуацию: пришел таск убрать некий блок. У нас сейчас достаточно скинуть задачу на верстака и он всё сделает. А так придется напрягать как верстака так и кодера. Круто? Я считаю что нет.

От организации зависит. Кроме того, если бы шаблон был активным, верстак все равно бы не убирал ручку, а только ее вызов. А это равносильно не убиранию лишних данных в логике (виде, активной составляющей шаблона), так что будет ("Ну и при поддержке нужно будет синхронизировать шаблон с логикой агрегации данных, а это лишний геморрой. Его не будет в активных шаблонах.")

Кроме того, следующий момент остался без примера:

Очень просто. Для пассивных шаблонов данные максимально соответствуют структуре представления. Если изменится view - нужно будет менять данные. Если будет несколько подобных view - либо для каждого агрегировать отдельный набор данных, либо использовать одни, но при этом может получится так, что для какого-то представления будут передаваться ненужные данные.

[B~Vladi]

И что значит "На объекте пространства имен шаблонизатора генерируется ошибка:"?

Да, замудрил. В общем, вот как это отлавливается:

TEN.on('error', function () {});

Какие сайчас могут быть ошибки на этапе шаблонизации:

1. Ошибки выполнения шаблона. Типо из JS-выражения обращаемся к неизвестной переменной.
Такие ошибки обрабатываются на том уровне, из которого вызывается шаблон для рендеринга, что логично. Некорректный кусок шаблона вместе со своим содержимым не выводится (или выводится отладочная инфа) и при этом никак не влияет на выполнение остального. К этим ошибкам так же относятся исключения, выкидываемые методами получения данных (ручка).

2. Ошибки получения данных. Типо:

ошибки работы с БД

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

В нем код записывается в виде кода, а не в виде разметки.

И этим он удобен? Странный вывод на мой взгляд. Мне жаль верстальщиков и кодеров, которые работают с этим.

верстак все равно бы не убирал ручку, а только ее вызов

Он и не должен этого делать.
Если бы задача стояла как: "выпилить такой-то блок со всего сайта", кодер выпилил бы ручку. Кодеру в любом случае как минимум нужно посмотреть таск. Если он хорошо знает систему, то сходу было бы ясно - выпиливать ручку или нет.

А это равносильно не убиранию лишних данных в логике

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

Это как? O.o

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

Кроме того, следующий момент остался без примера:

Ну ок, кодер реализовал вывод online-пользователей, прилепил к данным, которые будут отдаваться необходимому шаблону. Верстак написал шаблон. Потом приходит задача, показывать этот блок только в IE8, при полной луне и конкретном get-запросе. Как это лучше запилить? Прокинуть 3 лишних флага и верстак сам if-ами разрулит или пусть кодер это запилит? Пока ответь, а я потом продолжу сценарий.


Как я вижу рабочую ситуацию, используя мой подход с активными шаблонами:
Пришел таск: "вывести список online-пользователей". Таск переводится руководителем на кодера. Кодер реализует метод getOnline. В комментах к таску пишет: "Дернуть метод getOnline. Принимает аргументы: (бла бла), возвращает параметры: (бла бла)." и переводит на верстака.
Верстак пишет в шаблоне:

<ten:query method="getOnline" arguments="" params="error, data">
   <ten:if expr="data">
     <!-- обработка data -->
   </ten:if>
</ten:query>

Где тут много кода? Не намного больше чем в пассивном шаблоне.
Если придет задача вывести этот блок на другую страницу, кодер, зная что уже есть такой метод, перекинет таск сразу на верстака. Совершенно не задумываясь куда его нужно вставить.
Как тебе такой сценарий? Можно работать?

[x-yuri]

Какая-то у тебя странная категоризация ошибок: "К этим ошибкам [парсинга] так же относятся исключения, выкидываемые методами получения данных (ручка)." Какого плана исключения?

И этим он удобен? Странный вывод на мой взгляд. Мне жаль верстальщиков и кодеров, которые работают с этим.

Да, если у меня будет выбор между молотком и кувалдой, в случае, если мне надо забить гвоздь, я выберу молоток.

Кого кому жалко... не думаю, что это способствует конструктивному обсуждению...

А у php как шаблонизатора не большие недостатки (как для меня): 1) невозможно наследование шаблонов, 2) нереализуема защита от дурака, ну и от ошибок типа "забыл проэкранировать переменную". Знаешь, был какой-то период когда я возлагал слишком большие надежды на них (шаблонизаторы), а потом пришло понимание, что native php ни чем не хуже большинства существующих, а то и лучше. Ну и не только у меня так было. Наверное это был акт массового слабоумия

Он и не должен этого делать.
Если бы задача стояла как: "выпилить такой-то блок со всего сайта", кодер выпилил бы ручку. Кодеру в любом случае как минимум нужно посмотреть таск. Если он хорошо знает систему, то сходу было бы ясно - выпиливать ручку или нет.

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

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

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

у тебя тот же самый код, только записанный в неудобной для восприятия форме. Если бы у тебя ручки дергались декларативно... это было бы действительно качественное отличие.

Ну ок, кодер реализовал вывод online-пользователей, прилепил к данным, которые будут отдаваться необходимому шаблону. Верстак написал шаблон. Потом приходит задача, показывать этот блок только в IE8, при полной луне и конкретном get-запросе. Как это лучше запилить? Прокинуть 3 лишних флага и верстак сам if-ами разрулит или пусть кодер это запилит? Пока ответь, а я потом продолжу сценарий.

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

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

Где тут много кода? Не намного больше чем в пассивном шаблоне.

Ну давай сравним...

<ten:query method="getOnline" arguments="" params="error, data">
   <ten:if expr="data">
     <!-- обработка data -->
   </ten:if>
</ten:query>

{{#online_users}}
{{/online_users}}

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

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

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

Как тебе такой сценарий? Можно работать?

Мне-то точно не нравится, это у верстаков надо спрашивать...

[B~Vladi]

К этим ошибкам [парсинга]

Это не ошибки парсинга (компиляции). Это ошибки выполнения кода (синтаксические, эксепшны и т.п.).

Какого плана исключения?

Метод может выкинуть исключение.

Если бы у тебя ручки дергались декларативно... это было бы действительно качественное отличие.

Приведи пример. Желательно с учетом того, что ручки асинхронны.

Данные из url должны передаваться пассивным методом, из контроллера в шаблон, а остальное можно и активным.

Согласен, это можно легко организовать.

у тебя тот же самый код

Нет кода. Есть только конструкции и выражения внутри конструкций.

только записанный в неудобной для восприятия форме

Это твоё личное мнение

{{#online_users}}
{{/online_users}}

Где тут аргументы, параметры? Никакой реюзабельности, гибкости. Отдельный метод на конкретное действие. Если понадобится выводить 10 пользователей в одном месте, а 20 в другом - придется писать 2 метода. Так что пример не засчитан, c таким же успехом я могу написать так:

<ten:context object="online_users()">
</ten:context>

Потому что в твоем шаблоне рендеринг смешивается с кодом. Т.е. сложнее понять, что должно отрендериться.

В соседней теме люди писали что в основном всё понятно с первого взгляда, без доки. Может ты просто не понял самого принципа? Скажи какое конкретно место не понятно.

Мне-то точно не нравится, это у верстаков надо спрашивать...

Чем? Так работает весь маркет, все проекты на xscript-те. Только там активная и пассивная части разделены по файлам, у меня же всё вместе.

[x-yuri]

Это не ошибки парсинга (компиляции). Это ошибки выполнения кода (синтаксические, эксепшны и т.п.).

Метод может выкинуть исключение.

ну пускай не парсинга, но я бы в любом случае разделил на ошибки программиста и ошибки при обращении к ресурсам. И еще какие-то свои у тебя там исключения, эти я не знаю куда.

Приведи пример. Желательно с учетом того, что ручки асинхронны.

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

f(1, 2, 3)

<call function="f">
    <arg value="1">
    <arg value="2">
    <arg value="3">
</call>

Нет кода. Есть только конструкции и выражения внутри конструкций.

ты суслика видишь? Конструкции - это только оправдание. Типа это не код, это конструкции. Которые на самом деле код, императивный код.

Где тут аргументы, параметры? Никакой реюзабельности, гибкости. Отдельный метод на конкретное действие. Если понадобится выводить 10 пользователей в одном месте, а 20 в другом - придется писать 2 метода.

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

В соседней теме люди писали что в основном всё понятно с первого взгляда, без доки. Может ты просто не понял самого принципа? Скажи какое конкретно место не понятно.

я сказал сложнее понять, читабельность или ясность. Декларативные шаблоны легче понимать, чем императивные.

Чем? Так работает весь маркет, все проекты на xscript-те. Только там активная и пассивная части разделены по файлам, у меня же всё вместе.

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

[B~Vladi]

но я бы в любом случае разделил на ошибки программиста и ошибки при обращении к ресурсам

Они разделены, смотри пример выше.

И еще какие-то свои у тебя там исключения, эти я не знаю куда.

Я не знаю уже как объяснять. Мы, походу, о разных вещах говорим.
Вызвал функцию с аргументом - числом. Функция ожидала строку. Либо функция сама падает (например, пытается применить к аргументу метод строки), либо она проверяет тип и выкидывает исключение. Т.е. это то же самое, что и ошибка программиста, о которой ты писал выше.

Что касается ошибок обращения к ресурсам. Сами обращения происходят в недрах логики метода, вызываемого из шаблона, правильно? В ноде принято в callback первым параметром прокидывать объект ошибки, если это имеет место быть. Так вот, допустим в недрах этого метода возникла ошибка обращения к ресурсу и логика метода это отловила. Метод может передать в callback этот объект и уже в шаблоне на уровне разметки это обработается. Пример:

<ten:query method="getOnline" params="error, data">
  <ten:if expr="error">
    <!-- произошла ошибка доступа к ресурсам или ещё что -->
  <ten:else if="data" />
    <!-- всё ок, пришли данные, обрабатываем их -->
  </ten:if>
</ten:query>

Если ты про это говорил, то всё разделено. Если нет - расскажи на примере что ты имел ввиду.

f(1, 2, 3)

Это у меня записывается не так, не стоит надумывать
Тем более, в том же Dust можно вызывать функции и обрабатывать от них результат. Логика таких конструкций ничем не отличается от моего шаблонизатора (см. пример с query, context), кроме синтаксиса самих конструкций.

Которые на самом деле код, императивный код.

Любой шаблон на самом деле код. Тем более в JS. Почему, когда ты пишешь конструкцию в стиле Mu, ты не относишься к этому как к коду? Или я чего-то не до понял?

Для этого надо дергание ручки вынести из шаблона, а в шаблоне принять результирующие данные.

А мне не нравится такой подход. Мне страшно представлять огромное дерево данных. Особенно, когда они максимально соответствуют структуре представления. Пока никаких веских аргументов я не увидел (или плохо смотрел?), кроме религиозных убеждений. Из всего нашего диалога мне больше всего интересно узнать по-че-му надо так а не так? Я правда хочу знать, открой мне глаза

А записывание кода разметкой ничего не меняет, кроме понижения читабельности:

Ох. Ну где я записываю код разметкой? Вызовы методов? If-ы? Циклы? Кстати циклы (итераторы, ага), ифы, вызовы функций есть в каждом приличном шаблонизаторе. Чем мой от них отличается?
А, я понял. Тебе нравятся шаблоны типа:

<% for (var i; i < array.length; i++) { %>
<% } >

А не нравится тем, что это для меня не актуально

Хм. Поэтому не нравится? Т.е. если мне это не надо - то говно. Так получается?

ну так я и предлагаю разделить активную и пассивную составляющие по разным файлам.

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

Декларативные шаблоны легче понимать, чем императивные.

Требую пример кода декларативного шаблона и аналогичный код из моего, что бы были видны отличия.
Если не использовать некоторые конструкции в моем шаблонизаторе, то он ничем не будет отличаться от Mu или Dust.

[x-yuri]

Они разделены, смотри пример выше.

А, меня просто твои "исключения, выкидываемые методами получения данных (ручка)" сбили с толку.

Я не знаю уже как объяснять. Мы, походу, о разных вещах говорим.
Вызвал функцию с аргументом - числом. Функция ожидала строку. Либо функция сама падает (например, пытается применить к аргументу метод строки), либо она проверяет тип и выкидывает исключение. Т.е. это то же самое, что и ошибка программиста, о которой ты писал выше.

О, отлично объяснил. Я правда такими вещами не заморачиваюсь

Если ты про это говорил, то всё разделено. Если нет - расскажи на примере что ты имел ввиду.

если это то, о чем я думаю, то я говорил про разделение по файлам. Ну или хотя бы на две части в пределах файла: сначала код, потому - шаблон. А у тебя в перемешку.

Тем более, в том же Dust можно вызывать функции и обрабатывать от них результат.

О, а как?

Любой шаблон на самом деле код. Тем более в JS. Почему, когда ты пишешь конструкцию в стиле Mu, ты не относишься к этому как к коду? Или я чего-то не до понял?

есть код с состоянием (императивный) и побочными эффектами, а есть декларативный (функциональный) код.

А мне не нравится такой подход. Мне страшно представлять огромное дерево данных. Особенно, когда они максимально соответствуют структуре представления. Пока никаких веских аргументов я не увидел (или плохо смотрел?), кроме религиозных убеждений. Из всего нашего диалога мне больше всего интересно узнать по-че-му надо так а не так? Я правда хочу знать, открой мне глаза

1) я не говорю ограничиваться пассивным подходом, я говорю: "мухи отдельно, котлеты - отдельно", шаблон - без кода, код (вид) - без разметки; и я говорю: не надо писать код с помощью разметки (Вовочка, не качайся на папе, он не для того повесился); при этом каждый шаблон+вид могут принимать данные как пассивно, так и активно;

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

3) у меня складывается впечатление, что ты все что я говорю (по-крайней мере в последнее время) ты списываешь на религию, это так?

Ох. Ну где я записываю код разметкой? Вызовы методов?

они самые

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

и любишь же ты авторитетом давить, не своим, так чужим. Миллионы шаблонизаторов не могут ошибаться? Важно не то, что они что-то реализовали, а почему они это реализовали. Если тебе эта возможность нужна - используй.

Хм. Поэтому не нравится? Т.е. если мне это не надо - то говно. Так получается?

Мне-то точно не нравится, это у верстаков надо спрашивать...

Точнее кодеров спрашивать. Где я сказал говно? Я говорю, что передо мной не стоят твои проблемы и расскащываю, какие проблемы стоят передо мной. Хотя не то чтобы проблемы, скорее свои приоритеты.

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

Ну если для тебя это проблема, ее надо решать. Я ж не против.

Требую пример кода декларативного шаблона и аналогичный код из моего, что бы были видны отличия.
Если не использовать некоторые конструкции в моем шаблонизаторе, то он ничем не будет отличаться от Mu или Dust.

декларативный - в котором если и вызываются функции, то для преобразования, а не получения данных

да, давай приведу пример:

Пример: 1.xml

<?xml version="1.0" encoding="UTF-8"?>
<ten:root xmlns:ten="TEN" xmlns="http://www.w3.org/1999/xhtml">
    <ten:block>
    <ten:query method="getOnline" params="error, data">
        <ten:each object="data" item="user">
            <ten:echo data="user.name" />
        </ten:each>
    </ten:query>
    </ten:block>
</ten:root>

и как-нибудь так:

Пример: 1.mustache

{{#onlineUsers}}
    {{name}}
{{/onlineUsers}}

Пример: 1.js

this.onlineUsers = getOnline();

[B~Vladi]

А у тебя в перемешку.

Ну да, к этому и стремлюсь.

мухи отдельно, котлеты - отдельно

Мне известно это выражение и цель его ясна. Но я стараюсь смотреть на реальные потребности, в отличии от религии.

Вовочка, не качайся на папе, он не для того повесился

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

Ну моя заключается не только в этом (читай выше). Я пытаюсь объединить оба суждения.

у меня складывается впечатление, что ты все что я говорю (по-крайней мере в последнее время) ты списываешь на религию, это так?

Я больше не знаю как объяснить твою позицию. Я тебе приводил и код и нужды из жизни. Я же не против переосмыслить какие-то вещи, но для этого нужны причины, аргументы. Я готов слушать.

то я говорил про разделение по файлам

Смысл? Что даст? Православным станешь? (ога, я тролль )

и любишь же ты авторитетом давить, не своим, так чужим

Своего нет.

Где я сказал говно?

Ну ты сказал - тебе не нравится. Если ты не в курсе, для меня твоё мнение авторитетно, но нужны основания. Раз не нравится - значит говно, ну или окологовённое состояние.

для преобразования, а не получения данных

Мой шаблонизатор не первый в этом роде и этим пользуются (monolithed, помогай).

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

давай приведу пример:

Ну лучше же когда всё в одном месте, рядом. Может тебе просто стоит попробовать?! Я считаю стоит.

О, а как?

Да как и любое другое обращение к свойству. Если тип значения функция - она выполняется. Причем синхронно. А у меня можно и асинхронно. Ни у кого больше такого нет.