за какими именно проектами?

неочевидно, приведи пример

т.е. твой объединенный объединенный вариант - 3-ий вариант, который в зависимости от шаблона "получает нужные данные из источников и передаёт их одной пачкой в шаблон"? Так это чистый 3-ий вариант, получаемые данные определяются шаблоном в любом случае.

почему нет? Я слышал такой аргумент в пользу nodejs, собственно вот

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

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

вы какую-то свою терминологию (а может и реализацию) придумываете, вас трудно понимать. Самый распространенный вариант - контоллеры и экшены. Экшены - действия, контроллеры - группы действий. И url часто имеет вид: /[controller[/action[/id]]], например /users/delete/1 или /users

подожди, ты сравниваешь веб- и десктопные приложения? B~Vladi тебя не об этом спрашивал. И меня этот вопрос тоже интересует (в чем отличие твоей реализации?), потому что я не вкурил её, реализацию... :(

DjDiablo, я все еще помню, что ты обещал помочь с тестированием разобраться :\

p.s. карма напомнила ситуацию в Зимбабве

Раньше мне попадалось что-то подобное, но сейчас не вспомню конкретно. Сейчас - Яндекс.Маркет, например. Хотя там нельзя сказать, что данные запрашиваются из шаблона, но и не из контроллера или ещё чего-то.

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

В первом примере для генерации страницы агрегированием будет заниматься шаблон. Для AJAX-запросов какой-нибудь сервис/контроллер/как хотите.
Во втором примере вроде бы всё очевидно: для страницы данные формируются в одну пачку, для AJAX-запроса придется писать свой сервис/контроллер/как хотите

Ну не совсем. В третьем варианте контроллер обращается к источникам, а в объединенном дергаются ручки.

Реализация получения данных в контроллере будет разрастаться.

Возможно в каких-то частных случаях - да (либа там какая-нибудь), а так нет. То же XSL-преобразование. API везде разное ==> разный код.

Не не, всё на один хост/порт уходит с клиента. А статика да, на разные. Но она отдается nginx-ом, так что в контексте разговора нам не интересна.

Ну наверно, не до конца понял это определение. Предлагаешь делать по аналогии с express?

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



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

Кстати, да, даешь инфляцию в интернетах! :D

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

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

какие проблемы я вижу?

1) говрят, в процессе рендеринга шаблона, может выясниться, что другой блок надо перерендерить. Мне никаких конкретных примеров в голову не приходит.

Разве что несколько другой вариант, когда блок может потребовать подключить далее по тексту страницы нужные js-файлы или вставить нужный js-код (вариант, когда теги скрипт указаны перед </body>). Но это вроде решаемо.

Т.е. если обобщить: рендеринг блоков может влиять друг на друга, и должна быть возможность это как-то решать

2) как будут исключения/ошибки обрабатываться?

больше ничего не приходит в голову...

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

ну и не надо забывать, что есть POST (действие) и GET (вывод), т.е. не на каждый запрос надо рендерить шаблон.

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

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

вот и я о том же. Произошла ошибка при подключении какого-то блока в шаблоне. Как и где обработать эту ошибку?

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

php :)

:D как же я мог забыть об этом шаблонизаторе...

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

Чем?

Ну в любом случае это баг, его надо править. Отловить в контроллере это можно, отдав страницу 500 ну и с записью в лог, отправкой e-mail, sms, что угодно :)
Я считаю надо делать так.

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

слишком много знать будет, шаблон

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

кстати, откуда вообще берутся мысли про какие-то лишние данные в случае с пассивным шаблоном?

и расскажи подробнее, как происходит обработка запроса. А то я вот придумал ситуацию, но не знаю, возможно ли такое при твоем подходе: запускается рендеринг шаблона и когда дело доходит до основного контента выясняется, что 404 Not Found. Т.е. весь этот рендеринг выше был ненужным, чего хотелось бы избежать

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

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

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

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

На каком этапе(ах)?

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

Согласен. У меня получится, что само получение данных инкапсулировано в коде, а из шаблона идет только вызов и обработка ответа. Получается всё на своих местах.

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

Решено.

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

как?

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

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

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

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

да, потому что у тебя наследование недекларативное. Декларативность - проще и надежнее (сложнее сделать ошибку), но менее гибка, если это необходимо...

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