Исходное сообщение
"Архитектура 'тонкий сервер' с  обработкой данных на стороне клиента" Отправлено Serg, 28-Фев-08 17:11
Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы: 1. неоднозначность выполнения скрипта на клиенте, 2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню будут доступны? Это безопасность? 3. "не в базу напрямую" - это круто, Jumla тоже не напрямую в базу дает лезть, а всего лишь через параметры, можно отправить лекторов к milw0rm. 4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от сбоев решение... 5. >>вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы. Нет слов. А веб страница где? не на клиенте? Я почему-то думал, что страница живет в клиентском браузере, который может интерпретировать этот код, как ему заблагорассудится. 6. На кой черт проксировать запросы к другим ресурсам? Если ресурс мертв, данные проксика не валидны, если жив - их чудное приложение на клиенте может и само обрабатывать список зеркал, например. 7. Какая бизнес-логика? Кто решает, что будет видеть клиент? сервер? На основе тех данных и параметров, которые я могу задать в отладчике жабаскрипта? А давайте вернемся к отоплению жилья углем - от него дым прикольный... :)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы: > 1. неоднозначность выполнения скрипта на клиенте, > 2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню > будут доступны? Это безопасность? > 3. "не в базу напрямую" - это круто, Jumla тоже не напрямую > в базу дает лезть, а всего лишь через параметры, можно отправить > лекторов к milw0rm. > 4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от > сбоев решение... > 5. >>вы оcновное в этом подходе не поняли - код не загружается > отдельно клиентом. Он получает его с веб-страницы. > Нет слов. А веб страница где? не на клиенте? Я почему-то думал, > что страница живет в клиентском браузере, который может интерпретировать этот код, > как ему заблагорассудится. > 6. На кой черт проксировать запросы к другим ресурсам? Если ресурс мертв, > данные проксика не валидны, если жив - их чудное приложение на > клиенте может и само обрабатывать список зеркал, например. > 7. Какая бизнес-логика? Кто решает, что будет видеть клиент? сервер? На основе > тех данных и параметров, которые я могу задать в отладчике жабаскрипта? > А давайте вернемся к отоплению жилья углем - от него дым прикольный... > :)
	Введите код, изображенный на картинке: