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

[lsync]

Как быть со статикой и кешированием динамического контента?

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

Согласен. Хотя от шаблонизатора тоже зависит. Если он умеет описывать View-логику, то и сам сможет разрулить какой в итоге собрать шаблон, в зависимости от принятых данных.

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

Хорошо, напишу шаблон из одной строчки

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

[B~Vladi]

Для вывода JSON он и будет из одной строчки.

Я про это и говорил.

Об этом я писал выше, вы невнимательны.

Суть в том, что он не участвует в формировании страниц и ничего никуда не рулит при компоновке динамики. А вовсе не в том, что он бесполезен.

Это понятно. Но я пока всё равно не вижу причин не использовать nginx в качестве роутера. Проксировать он умеет прекрасно, это его одна из основных возможностей, так почему бы ей не воспользоваться?

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

Конечно, используемый мной шаблонизатор это умеет.

[devote]

B~Vladi,
раз уж тут такая пьянка, попробую рассказать о своей системе реализованной на собственном движке.

Реализация у меня такова, кратко:
1. Шаблон, выступает в качестве client-side/virtual-client-side приложения, никак не связанного c View и ни с чем другим. Собственно он дергает ручки контролера.
2. Контролер, занимается перенаправлением требований от client-side и не более того, то-есть client-side дергает ручку контрола, контрол дергает нужную модель, на основе запроса.
3. модель, собственно занимается формированием данных, обработкой запросов и т.д. Формирует данные и отдает их уже выходному view.
4. View, собственно отвечает за то в каком виде отдать клиентской части данные, в формате JSON ( тоесть по запросу AJAX ) либо уже сформированное view представление.

Вот собственно модель работы моего движка. Конечно нюансы есть где-то, но принцип примерно такой.

[B~Vladi]

либо уже сформированное view представление.

Т.е. прогоняет через шаблонизатор? А что тогда такое "шаблон" из п.1? Какая-то рекурсия получается

ЗЫ: немо 3 поста (!) написал и даже нахуй никого не послал
Походу настроение хорошее было...

[devote]

Т.е. прогоняет через шаблонизатор? А что тогда такое "шаблон" из п.1? Какая-то рекурсия получается

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

[B~Vladi]

devote, понятно, но принципиальных отличий не заметил от того, к чему мы пришли выше.

[devote]

ой, не MVCM а получается MVVC

[devote]

но принципиальных отличий не заметил от того, к чему мы пришли выше.

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

[Shaci]

сверху вниз

Магазины, сети, качественные порталы.

генерируемая система для готовых решений

Модули->апи, контролеры, выходные файлы->css,js,csv lung, формы, модели->таблицы,плагины,настройк� �->router,content,вьюшки помошники, вьюшки штмлки, виджеты,publick files, бустстрап, библиотеки.


особенности, отлично знать фронт, знать оптимизацию бд, алгоритмы.


качай готовый двиг и переделывайЮ ты с готовым замучаешься не то что делать кривой

вторая буква Е?

[B~Vladi]

вторая буква Е?

Других вариантов просто быть не может:

немо 3 поста (!) написал