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

[x-yuri]

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

Аналогично, для меня твои реальные потребности - религия.

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

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

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

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

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

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

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

Ну да, я неудачно выразился. Я просто имел в виду, что для меня это не проблема. И когда я говорю "не нравится", я подразумеваю, что это не объективно, или что я в данный момент не стремлюсь к объективности.

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

да, monolithed, помогай, а то скучно уже вдвоём становится...

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

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

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

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

[monolithed]

да, monolithed, помогай, а то скучно уже вдвоём становится...

А почему вы обсуждаете синтаксис шаблонизатора, а не его фичи или их отстутствие (хотя с этого начали)?

[x-yuri]

А почему вы обсуждаете синтаксис шаблонизатора, а не его фичи или их отстутствие (хотя с этого начали)?

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

[monolithed]

При чем не столько синтаксис, сколько, должна ли такая быть, входит ли такое в обязанности шаблонизатора

Если брать такие шаблонизаторы как {{mustaches}}, TSN, Jade, Yammy и пр., то на мой взгляд основная их проблема в том, что пользователь работает не с XML-кодом, а с "текстом", который потом еще нужно прогонять через валидатор, т.е. привинчивать еще один XML-парсер вместо того чтобы сделать все одним инструментом.

С другой стороны, как сказал B~Vladi, TSN может работать с любым форматом данных, поэтому нет смысла привязываться к XML.
Тогда почему бы не сделать дополнение для шаблонизатора, которое бы проверяло валидность XML-кода?

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

И почему это отсутствие можно обсуждать, а присутствие нельзя?

Я имел ввиду, то что шаблонизатор B~Vladi, XML-подобный и приводить в пример {{mustaches}} не совсем корректно, т.к. XML-синтаксис довольно ограничен в минималистичности и сделать что-то проще очень сложно.

PS: Еще меня сильно смущает, тот факт что шаблонизатору слишком многое дозволено:

<tsn:if>
	<tsn:else if="typeof this === 'string'" />
</tsn:if>

Если уж отделять логику от представления, то этой логике (typeof this === 'string') явно в шаблоне не место

[B~Vladi]

Тогда почему бы не сделать дополнение для шаблонизатора, которое бы проверяло валидность XML-кода?

Периодически возникает такая мысль, но когда я смотрю на свою IDE - передумываю, ибо она сама и есть валидатор.
И ещё вопрос - что валидировать? Исходный код или конечный результат? Исходный валидирует IDE, конечный тот инструмент, которому он отдается (браузер, например).

меня сильно смущает, тот факт что шаблонизатору слишком многое дозволено

Это холиварный вопрос. Либо делать поддержку только простых выражений, либо делать полноценные. Я выбрал второе, что бы потом не было дискомфорта от ограничений.
Ну и опять же, никто не запрещает валидировать эти данные до входа в шаблон.

А в чем еще?

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

Ты готов слушать о том, что твоя проблема на самом деле не проблема?

Если у тебя есть аргументы - да.

Лучше, когда все что нужно в одном месте.

Вот! И я о том же. В xscript-е мне приходится постоянно держать перед глазами 3 окна - XML-файл, XML-выдачу и XSL шаблон. Это адски неудобно. Но это составляет единый механизм, поэтому в tsn первое и третье объединено.

можно ли функции параметры передавать как-то

Я хз, вроде никак. Этим он и ущербный, имхо.

должна ли такая быть, входит ли такое в обязанности шаблонизатора

У каждого своё представление о том, что должен уметь шаблонизатор. Наверное, все сходятся только в одном - он должен уметь то, что в него заложили разработчики. А что они реализуют - их личное дело.

Ещё раз хочу обратить внимание, что TSN не принуждает к использованию какой-то конкретной модели шаблонизации. Хочешь - пишешь пассивный шаблон и не пользуешься этими вызовами. Хочешь - активный.
То же самое и с выражениями. Если видишь, что typeof-у не место в шаблоне - выноси в логику и совесть будет чиста.

фичу-дергания-ручек-прямо-из-шаблонизатора

Да классная штука, чо
monolithed, расскажи нам, что вам это дает? И даёт ли.

[x-yuri]

Если брать такие шаблонизаторы как {{mustaches}}, TSN, Jade, Yammy и пр., то на мой взгляд основная их проблема в том, что пользователь работает не с XML-кодом, а с "текстом", который потом еще нужно прогонять через валидатор, т.е. привинчивать еще один XML-парсер вместо того чтобы сделать все одним инструментом.

Честно говоря, не понял. Если там не xml, зачем там xml-парсер?

Я имел ввиду, то что шаблонизатор B~Vladi, XML-подобный и приводить в пример {{mustaches}} не совсем корректно, т.к. XML-синтаксис довольно ограничен в минималистичности и сделать что-то проще очень сложно.

согласен, вопрос в том, имеет ли смысл усложнять синтаксис с помощью xml

Этой логике (typeof this === 'string') явно в шаблоне не место

ну тут два выхода: либо, пытаться с этим как-то бороться, либо не пытаться. На мой взгляд не надо, а кто будет так писать, ССЗБ. Но возможно кому-то надо бороться...

[B~Vladi]

Пример: 1.xml

Тег block лишний.
Так как функция getOnline синхронна, нет смысла вызывать её из query.
Шаблон должен выглядеть так:

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

Или так:

<ten:each object="getOnline()" item="user">
    <ten:echo data="user.name" />
</ten:each>

[x-yuri]

Вот! И я о том же. В xscript-е мне приходится постоянно держать перед глазами 3 окна - XML-файл, XML-выдачу и XSL шаблон. Это адски неудобно. Но это составляет единый механизм, поэтому в tsn первое и третье объединено.

если это проблема, может стоит сменить ide? у меня код, отсносящийся к страничке находится в контроллере, виде, шаблоне, js-файле и css-файле. Было бы грустно, если бы оно все было в одном файле. И как-то столько файлов неудобств не вызывают, обычно. Возможно, что-то из этого можно было бы объединить в один файл, опционально, но точно не в одну кучу (как ты предлагаешь), а последовательно, одно за другим.

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

а чего это getOnline - синхронна?

p.s. сорри, не особо старался сделать оптимальный tsn-шаблон...

[B~Vladi]

может стоит сменить ide?

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

но точно не в одну кучу (как ты предлагаешь),

Я не предлагал всё, только view (включая view-логику).

а чего это getOnline - синхронна?

Ну так ты сам написал:

this.onlineUsers = getOnline();

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

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

[x-yuri]

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

я с xscript не работал, но по опыту работы с несколькими файлами на страницы могу сказать, что для меня это проблем не создает и объединить в один файл желания не возникает. Бывает наоборот удобно открыть один и тот же файл в двух соседних вкладках. Поэтому я предположил, что дело в ide.

Я не предлагал всё, только view (включая view-логику).

да, я именно об этом

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

потому что: 1) у меня нету такой проблемы, 2) не уверен, что это распространенная проблема, 2.1) если так, то это ненужное усложнение.