Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 152
для меня нечто новое и интересное…
Спасибо.
В принципе, подобные идеи (о полном отказе от генерации HTML-кода на сервере) в неявном виде витали в воздухе уже давно. См. например статью «Ajax-машина».
Возможно, я прото один из первых сформулировал ее.
В принципе, подобные идеи (о полном отказе от генерации HTML-кода на сервере) в неявном виде витали в воздухе уже давно. См. например статью «Ajax-машина».
Возможно, я прото один из первых сформулировал ее.
Единственное, что не сформулировано — это зачем? какие из показателей станут лучше? скорость загрузки приложения? время отклика? уровень загруженности сервера? скорость разработки сайта?
Сейчас постараюсь написать подробный ответ.
Любая модификация проекта станет намного легче.
Хм, опять же чем?
Нет.
Модификация проекта намного усложнится.
Представьте, что нужно будет добавить новый блок с данными — что разве не нужно будет переписывать генерацию кода?
И есть еще, более важный момент — кеширование!
В случае когда сервер генерит код интерфейса, можно использовать кеширование — один раз запросил, все остальные разы берутся из кеша…
В случае генерации кода у клиента, как вы собираетесь кешировать код?
Лично мне такой подход не нравится, нечего заставлять мой комп выполнять двойную работу — сперва генерировать код, а потом еще и отображать и с ним работать…
Модификация проекта намного усложнится.
Представьте, что нужно будет добавить новый блок с данными — что разве не нужно будет переписывать генерацию кода?
И есть еще, более важный момент — кеширование!
В случае когда сервер генерит код интерфейса, можно использовать кеширование — один раз запросил, все остальные разы берутся из кеша…
В случае генерации кода у клиента, как вы собираетесь кешировать код?
Лично мне такой подход не нравится, нечего заставлять мой комп выполнять двойную работу — сперва генерировать код, а потом еще и отображать и с ним работать…
Я имел в виду четкое разделение по обязанностям. Кеширование помогает снизить траффик между сервером и клиентом, зачем вообще что-то кешировать в интерфейсе при таком подходе?
А как же другая логика,
зачем каждый раз генерить сам интерфейс-то?
Он же не меняется, а меняются только данные.
К примеру, берем самую обычную «шапку» сайта, с меню первого уровня.
В вашем случае, при каждом обращении к страницам сайта, этот блок (меню) будет заного генериться и генериться. Но зачем такое нужно? Зачем тратить ресурсы на бессмысленную операцию — генерим то, что не меняется.
При генерациии на сервере, можно было интерфейс сгенерить единожды, а потом отдавать тока из кеша.
зачем каждый раз генерить сам интерфейс-то?
Он же не меняется, а меняются только данные.
К примеру, берем самую обычную «шапку» сайта, с меню первого уровня.
В вашем случае, при каждом обращении к страницам сайта, этот блок (меню) будет заного генериться и генериться. Но зачем такое нужно? Зачем тратить ресурсы на бессмысленную операцию — генерим то, что не меняется.
При генерациии на сервере, можно было интерфейс сгенерить единожды, а потом отдавать тока из кеша.
Другая логика в разделении кода и представления и в распределении нагрузки. По-моему вполне логично.
По поводу кэширования. А оно просто не нужно в этом случае для клиентского интерфейса, кэшировать можно только отдаваемые данные.
К тому же мы снижаем нагрузку на сервер и распределяем ее на клиентов — что хорошо.
Идея, описанная в статье мне, в общем, понравилась.
По поводу кэширования. А оно просто не нужно в этом случае для клиентского интерфейса, кэшировать можно только отдаваемые данные.
К тому же мы снижаем нагрузку на сервер и распределяем ее на клиентов — что хорошо.
Идея, описанная в статье мне, в общем, понравилась.
Присоединюсь к этому вопросу — не понятна преследуемая цель. Если цель заключается в том, что «web-сервер не генерирует ни строчки HTML», то достаточно было только описать что уходит к клиенту и протокол сервера. На чем и как реализован сервер — уже становится не важно.
А модификации всегда идут легко, если система хорошо спроектирована.
Да, возможно статью более четко характеризовали словосочетания «Абсолютный» или «Полный Аякс»
А модификации всегда идут легко, если система хорошо спроектирована.
Да, возможно статью более четко характеризовали словосочетания «Абсолютный» или «Полный Аякс»
Кстати вполне возможно, что все эти параметры разом :) Смотря как вы делали веб-приложения раньше, и какова будет реализация данного подхода.
Ну вот делал я приложения на основе, к примеру, GWT. Что мне даст совершенство вашего AJAX'а?
Буду краток.
— скорость загрузки приложения:
будет меньше (хуже), чем у классического приложения, за счет того, что этап «запуска» такого приложения, по сути, этап полной загрузки исходного кода клиента. Но в дальнейшем таких «тяжелых» запросов не будет, а вот при классическом подходе очень даже возможно. В двух словах, график загрузки клиента сначала взлетит «в небо», по сравнению с классическим, но потом трафик будет идти только за счет относительно небольших ajax запросов, а в классике траф будет расти постоянно лесенкой, при каждой загрузке страницы. Это плюс любого ajax приложения вообще, с самого начала раскрутки ajax в инете графики были известны. [Плюшки: задачи проще делить физически между программистами/командами/фирмами и т.д., можно сделать несколько клиентов, можно опубликовать апи и т.д.]
— время отклика: что быстрее серверу, сформировать и выплюнуть html-страничку, (обычно это куча инклюдов или их аналогов, дергание кучи кода и т.д.) или же отдать компактный ответ в JSON (Ну или на худой конец в XML)? Подумайте сами. Плюс подхода — стандартизация, из клиента мы может обращаться к веб-сервису, для примера. [Разработка: проще построить стандартизированное монолитное приложение, проще сопровождать, можно обсудить подробнее]
— уровень загруженности сервера: прямо зависит от двух прошлых пунктов, сами сделайте вывод, что больше грузит сервер. (Если у вас не новостной проект и вы не отдаете статику) [Разработка: проще рулить нагрузкой, ваш клиент может обращатся к 3-4 независимым сервисам, допустим]
— скорость разработки сайта: зависит от команды и от ее опыта, а так же от наличия подходящего инструментария в виде фреймворков и т.д. Тут все очень субьективно.
Простите, на работе нет времени на более подробный ответ.
— скорость загрузки приложения:
будет меньше (хуже), чем у классического приложения, за счет того, что этап «запуска» такого приложения, по сути, этап полной загрузки исходного кода клиента. Но в дальнейшем таких «тяжелых» запросов не будет, а вот при классическом подходе очень даже возможно. В двух словах, график загрузки клиента сначала взлетит «в небо», по сравнению с классическим, но потом трафик будет идти только за счет относительно небольших ajax запросов, а в классике траф будет расти постоянно лесенкой, при каждой загрузке страницы. Это плюс любого ajax приложения вообще, с самого начала раскрутки ajax в инете графики были известны. [Плюшки: задачи проще делить физически между программистами/командами/фирмами и т.д., можно сделать несколько клиентов, можно опубликовать апи и т.д.]
— время отклика: что быстрее серверу, сформировать и выплюнуть html-страничку, (обычно это куча инклюдов или их аналогов, дергание кучи кода и т.д.) или же отдать компактный ответ в JSON (Ну или на худой конец в XML)? Подумайте сами. Плюс подхода — стандартизация, из клиента мы может обращаться к веб-сервису, для примера. [Разработка: проще построить стандартизированное монолитное приложение, проще сопровождать, можно обсудить подробнее]
— уровень загруженности сервера: прямо зависит от двух прошлых пунктов, сами сделайте вывод, что больше грузит сервер. (Если у вас не новостной проект и вы не отдаете статику) [Разработка: проще рулить нагрузкой, ваш клиент может обращатся к 3-4 независимым сервисам, допустим]
— скорость разработки сайта: зависит от команды и от ее опыта, а так же от наличия подходящего инструментария в виде фреймворков и т.д. Тут все очень субьективно.
Простите, на работе нет времени на более подробный ответ.
— по скорости загрузки — не обязательно хуже. Код классов может пригружаться по мере использования (с ходу: фабрика при создании объекта проверяет наличие соответствующего класса, если его нет — то пригрузка js-файла и создание объекта)
— время отклика: тут стоило написать «объём передаваемых данных». Вы действительно считаете, что подставить данные в шаблон намного тяжелее, чем обернуть их в JSON или XML? Работа с файлами (например, обработка картинки), выборки из БД, вычисления — всё это останется неизменным.
Про плюс в виде стандартизации я не совсем понял. Что конкретно имеется ввиду?
Про плюс в виде стандартизации я не совсем понял. Что конкретно имеется ввиду?
Если мы говорим про RIA приложения, т.е. про приложения достаточно нагруженные клиентской логикой, красивым UI и т.д. то да, я действительно считаю, что передать структуру, допустим «акции», обновляющиеся раз в минуту в виде:
{
{
имя: «MSFT»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
},
{
имя: «GOOG»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
}
}
гораздо мение накладно, чем каждый раз генерить полную страничку с этой информацией. И чем сложнее приложение (отображение истории, динамики и т.д.) тем больше будет заметна эта разница. Хотя, я может быть вас не совсем понял, тогда извиняюсь.
Под стандартизацией я подразумевал возможность проецировать архитектуру такого приложения на существующие идеологии веб-сервисов или REST, к примеру — и как итог получить в распоряжение весь инструментарий доступный для них: фреймворки, стандарты и т.д. Прошу прощения, не успеваю раскрыть мысль, нужно бежать.
{
{
имя: «MSFT»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
},
{
имя: «GOOG»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
}
}
гораздо мение накладно, чем каждый раз генерить полную страничку с этой информацией. И чем сложнее приложение (отображение истории, динамики и т.д.) тем больше будет заметна эта разница. Хотя, я может быть вас не совсем понял, тогда извиняюсь.
Под стандартизацией я подразумевал возможность проецировать архитектуру такого приложения на существующие идеологии веб-сервисов или REST, к примеру — и как итог получить в распоряжение весь инструментарий доступный для них: фреймворки, стандарты и т.д. Прошу прощения, не успеваю раскрыть мысль, нужно бежать.
Вижу проблему с SEO ;)
Непонятно почему сформировать и выплюнуть html-страничку медленнее чем дать компактный ответ в JSON. Одного порядка должны быть величины, по-моему. При правильной организации приложения кучи инклуда и дерганье кучи кода не должно произойти. Ошибаюсь?
Ну то на клиент пришел ответ { my_param = 32; } и js сделал my_element.innerHTML = my_param
А то на клиент пришел целый HTML с HEAD блоком, BODY с кучей элементов. Мало того что пришел больший объем информации, так еще эти все элементы браузер должен создать в памяти, а у каждого свой стилевой класс с кучей аттрибутов. Т.е. вместо того чтобы клиент просто сделал запись в innerHTML, браузер заного рендерит всю страницу.
А то на клиент пришел целый HTML с HEAD блоком, BODY с кучей элементов. Мало того что пришел больший объем информации, так еще эти все элементы браузер должен создать в памяти, а у каждого свой стилевой класс с кучей аттрибутов. Т.е. вместо того чтобы клиент просто сделал запись в innerHTML, браузер заного рендерит всю страницу.
Если ни хотите мучится с шаблонизатором и HTML, то xsl вам в руки вперед, зачем так все усложнять?
меня интересует тот же самый вопрос. Совсем не понял, зачем все это надо в реальности? Может быть, в силу того, что я тут не все понял, я не понимаю зачем все это надо :)
Идея витает уже очень давно… и первым вы ее сформулировали разве что на Хабре.
Гдето годика полтора назад я начинал реализацию похожего по идеологии продукта. Сделали Дельфи-подобный конструктор экранных форм и реализацию на «клиенте»(в браузере), дело было всего лишь за созданием компонентов. К сожалению, по левым причинам разработку закрыли. думаю, что скоро появится что-то серьезное в эту тему.
Гдето годика полтора назад я начинал реализацию похожего по идеологии продукта. Сделали Дельфи-подобный конструктор экранных форм и реализацию на «клиенте»(в браузере), дело было всего лишь за созданием компонентов. К сожалению, по левым причинам разработку закрыли. думаю, что скоро появится что-то серьезное в эту тему.
Немного не в тему, но перед тем как прочесть автора, зашел в блог и посмотрел как сам автор «дружит» с web. Знаете, порадовало сразу, что блог проходит валидацию. Только после этого прочел всю статью.
Уж больно она большая :) Если бы не прошел валидацию блог, врядли читал всю.
Уж больно она большая :) Если бы не прошел валидацию блог, врядли читал всю.
Бизнес-логика не смешивается с пользовательским интерфейсом
А что, в Вашем случае на стороне клиента они не смешиваются?
в статье четко прослеживаются некоторые моменты из архитектуры Hivext. Спасибо что указали где подсмотрели :).
в статье четко прослеживаются некоторые моменты из архитектуры Hivext. Спасибо что указали где подсмотрели :).
Ну не совсем :-) Мы используем подход «Совершенный Ajax» уже больше чем полтора года.
Просто сформулировать его и написать статью я решил сейчас. Статья про Hivext чуточку опередила :)
Но, еще раз повторю, идеи отказа от генерации HTML-кода на сервере в неявном виде витали в воздухе уже давно. И мы дошли до них разными путями.
Я лишь решил сформулировать эту мысль явно.
думаю конкретно в генерации HTML кода на сервере нет ничего плохого, по сути это тот же XML, все зависит от выполняемой задачи
по сути необходимо разделить представление данных от самих данных
статья интересная, успехов в развитии
по сути необходимо разделить представление данных от самих данных
статья интересная, успехов в развитии
Понравилась статья, спасибо! Сейчас размышляю над похожей архитектурой.
Сейчас мне видятся такие плюсы от отказа генерации html на сервере:
1) можно делать интерфейсы не только для веб, но и для десктоп. Вы об этом написали.
2) Хорошо подходит для задач, типа обновлять курс валют каждые пару минут
Но и минусы не далеко:
1) Возможность делать интерфейсы для веб, десктопа и т.п. можно и другими способами — используя REST. Мне сейчас это кажется более удобным для этих задач. Тем более у Вас вся логика происходит все равно на Вашем сервере. Если бы нужно было некоторое время программе работать оффлайн, то тут Ваша архитектура могла бы выиграть.
2) Для задач, типа обновления курса валют, можно вполне первый раз сгенерировать интерфейс на сервере и дальше подгружть данные по Аякс. Это выглядит просто легче в реализации для такой простой задачи.
Т.е. получается пока выгода от такого подхода для меня сомнительна. Возможно, что я не врубился в какие-то тонкости. Хотелось бы врубиться :))
Сейчас мне видятся такие плюсы от отказа генерации html на сервере:
1) можно делать интерфейсы не только для веб, но и для десктоп. Вы об этом написали.
2) Хорошо подходит для задач, типа обновлять курс валют каждые пару минут
Но и минусы не далеко:
1) Возможность делать интерфейсы для веб, десктопа и т.п. можно и другими способами — используя REST. Мне сейчас это кажется более удобным для этих задач. Тем более у Вас вся логика происходит все равно на Вашем сервере. Если бы нужно было некоторое время программе работать оффлайн, то тут Ваша архитектура могла бы выиграть.
2) Для задач, типа обновления курса валют, можно вполне первый раз сгенерировать интерфейс на сервере и дальше подгружть данные по Аякс. Это выглядит просто легче в реализации для такой простой задачи.
Т.е. получается пока выгода от такого подхода для меня сомнительна. Возможно, что я не врубился в какие-то тонкости. Хотелось бы врубиться :))
Интересная статья, правда как-то трудно переосмыслить что весь пользовательский интерфейс генерируется на клиенте. То есть понадобится ли для этого какая-то настройка клиента?
То есть понадобится ли для этого какая-то настройка клиента?Нет, зачем?
Весь клиентский web-интерфейс представляет собой простой набор HTML-страниц.
При стром подходе, данные «впечатывались» сервером.
При новом подходе, web-страница сама загружает нужные данные через Ajax, и с помощью JS управляет собственным интерфейсом.
В принципе, так работает большинство обычных клиент-серверных приложений. Ведь, например, программа на Delphi не генерируется сервером; а самостоятельно загружает с него данные.
И я хочу показать, что HTML-страницы ничем не хуже в этом плане, чем, например, WinForms.
Интересно но данные о том как должна выглядеть страница, начальный шаблон страница (HTML) берутся с того же сервера. Скорее всего для полного понятия чего к кому нужно дождаться следующую публикацию, очень жду )))
HTML может придти откуда угодно. С сервера он скачивается «прозрачно» в виде файла (который не генерируется динамически). Точно так же как скачиваются файлы *.js, *.css, картинки и т.п.
Но все равно — для каждой странице существует свое дерево тегов. Ведь так? Если мы хотим вставить небольшой компонент сайта на другой сайт — сделать машап, то нам придется запрашивать с сервера дерево этого маленького компонента. Вот и опять все сводится к тому, что у нас на сервере лежит куча шаблонов под разные компоненты. Да, в них нет стилей. Возможно это плюс. Но сейчас не пойму насколько это плюс.
Если мы запрашиваем компонент с сервера, то скорее всего уже давно известно, что этот компонент будет в итоге списком, а не деревом. Так почему бы сразу не передать команду, что это список, а не выполнять код по инициализации этого списка.
Т.е. я не пойму, когда возникают задачи, что нам нужно список вдруг превратить в дерево? Но сама идея интересная…
Если мы запрашиваем компонент с сервера, то скорее всего уже давно известно, что этот компонент будет в итоге списком, а не деревом. Так почему бы сразу не передать команду, что это список, а не выполнять код по инициализации этого списка.
Т.е. я не пойму, когда возникают задачи, что нам нужно список вдруг превратить в дерево? Но сама идея интересная…
Ajax-машина хороша для административной зоны сайта, но для страниц где важна поисковая оптимизация это вряд ли подойдет — поисковые роботы не любят javascript.
«Ajax-машина» или Архитектура «Совершенный Ajax» предназначена для web-приложений (программ).
Для сайтов, Вы совершенно правы, следует использовать традиционный подход.
Для сайтов, Вы совершенно правы, следует использовать традиционный подход.
это смотря как выдавать javascript и как хранить контент,
очень всё даже нравится этим роботам.
очень всё даже нравится этим роботам.
можно ссылок или деталей?
сохранять html версии страниц с контентом(можно его частью) для индексации в отдельную папку,
в robots.txt разрешить индексировать только её.
На каждой такой странице ставить ссылку типа «на главную» или «подробнее» которая уже ведёт юзера на сайт.
при обновлении страницы в базе обновлять и её файл.
js и css сжимать объединять и хранить в закрытой для роботов дирректории, как собственно всё остальное.
ах, да:
— это моё личное мнение, возможно в корне неверное, но до сих пор работающее )
— я не SEO'шник(плохо разбираюсь в способах раскрутки), у вас там пожалуй есть какие-нибудь свои заморочки о которых я не знаю.
просто:
— часто встречаю на первых местах в поисковиках, архивные страницы форумов, и файлы для печати.
— wordpress делает что-то типа.
— как-то делал сайтик… хостер не предоставлял mysql, все данные я решил хранить в обычных .txt, сайт быстро вылез на первую страницу яндекса без какой — либо дополнительной раскрутки.
в robots.txt разрешить индексировать только её.
На каждой такой странице ставить ссылку типа «на главную» или «подробнее» которая уже ведёт юзера на сайт.
при обновлении страницы в базе обновлять и её файл.
js и css сжимать объединять и хранить в закрытой для роботов дирректории, как собственно всё остальное.
ах, да:
— это моё личное мнение, возможно в корне неверное, но до сих пор работающее )
— я не SEO'шник(плохо разбираюсь в способах раскрутки), у вас там пожалуй есть какие-нибудь свои заморочки о которых я не знаю.
просто:
— часто встречаю на первых местах в поисковиках, архивные страницы форумов, и файлы для печати.
— wordpress делает что-то типа.
— как-то делал сайтик… хостер не предоставлял mysql, все данные я решил хранить в обычных .txt, сайт быстро вылез на первую страницу яндекса без какой — либо дополнительной раскрутки.
ЗЫ: сформировал мысль!
Дай роботу то что он хочет, а сам делай то, что хочешь ты ))
Дай роботу то что он хочет, а сам делай то, что хочешь ты ))
То есть как сохранять отдельно?
Делать копии всех страниц в традиционном виде?
Или я не понял чего-то?
Делать копии всех страниц в традиционном виде?
Или я не понял чего-то?
Да-да, именно так.
Только не говорите, что это нерациональное использование места на хостинге.
Только не говорите, что это нерациональное использование места на хостинге.
(1) Это нерациональное использование труда программиста — в итоге получается два сайта: один для пользователя, другой для поисковика.
(2) Еще есть проблема ссылок — при использовании ajax меняется содержимое страницы, но не адресная строка вашего браузера. Вы не сможете послать ссылку другу на интересный материал просто скопировав адресную строку.
(2) Еще есть проблема ссылок — при использовании ajax меняется содержимое страницы, но не адресная строка вашего браузера. Вы не сможете послать ссылку другу на интересный материал просто скопировав адресную строку.
Опередили. )
пункт 1 — всё генерится автоматически, никакого труда программиста не требуется
пункт 2 — решаем через хэш
пункт 2 — решаем через хэш
А подробнее можно? На данный момент для меня это пустые слова.
зацени как сделано durov.ru/, ссылки нормально передаются
или kgdtour.ru/#159 — «корпоративным клиентам»(реализовано по-дурацки, но суть думаю ясна)
habrahabr.ru/blogs/webdev/31211/ — тут много написано как «сэмулировать» переход по страницам.
или kgdtour.ru/#159 — «корпоративным клиентам»(реализовано по-дурацки, но суть думаю ясна)
habrahabr.ru/blogs/webdev/31211/ — тут много написано как «сэмулировать» переход по страницам.
блин, страница «корпоративным клиентам» — пустая
вот лучше kgdtour.ru/#173 — «Контакты»
вот лучше kgdtour.ru/#173 — «Контакты»
OK — про ссылки убедили. Будет сложно, конечно, реализовать когда на странице несколько динамических элементов и куча комбинаций их состояний, но это решаемо. Но хотелось бы посмотреть на более сложные примеры применения, а не только когда меняется контент в одной ячейке как на kgdtour.ru.
> Это нерациональное использование труда программиста —
> в итоге получается два сайта: один для пользователя,
> другой для поисковика.
Я убиваться об стену делая нечто, что прокатит и тому и другому, сцуко очень рациональное использование!
> в итоге получается два сайта: один для пользователя,
> другой для поисковика.
Я убиваться об стену делая нечто, что прокатит и тому и другому, сцуко очень рациональное использование!
Т.е. написать сайт два раза?
нет, просто после функции добавления записи в базу, дописать функцию (пере)записи того же в файл.html, с соответствующим заголовком и мета тегами.
Это подойдет для простого сайта типа kgdtour.ru — когда меняется только одна центральная часть, а представите когда на странице может быть несколько динамических элементов — количество комбинаций возрастает, замучаетесь генерировать.
habrahabr.ru/blogs/webdev/31211/ — тут автор рассказывает о вертикальных и горизонтальных ссылках, почитайте.
и ещё раз — durov.ru/ отличный пример с «кучей динамических элементов».
Генерирует все простой алгоритм автоматически, размер кода при этом особо не увеличивается.
Знаете, подходы могут быть разные, мне так просто удобнее и нет смысла об этом спорить.
Интересна точка зрения seo'шников, в плане эффективности такого подхода для раскрутки.
и ещё раз — durov.ru/ отличный пример с «кучей динамических элементов».
Генерирует все простой алгоритм автоматически, размер кода при этом особо не увеличивается.
Знаете, подходы могут быть разные, мне так просто удобнее и нет смысла об этом спорить.
Интересна точка зрения seo'шников, в плане эффективности такого подхода для раскрутки.
Всему свое. Пока для сайтов такой подход не подходит) им html для SEO + слой js для красоты и удобства.
Яваскрипт и его последствия ставится в последнуюю очередь. И обычно без яваскрипта все работает также хорошо как и с ним.
Для сайта JS нужен, чтобы сделать первичную валидацию на клиенте, различные энчанты форм и картинок + не особо нужные виджеты такие как чаты, ajax голосовалки, «загрузка статьи из читать дальше». Ни для чего больше js не подходит на обычном сайте.
Для веб-приложений(емейл клиенты, админки ЦМС и т.п.) подход «все на javascript» идеален. SEO важно и совсем не нужено, у клиента все крутится быстро и красиво и без лишних затрат.
Яваскрипт и его последствия ставится в последнуюю очередь. И обычно без яваскрипта все работает также хорошо как и с ним.
Для сайта JS нужен, чтобы сделать первичную валидацию на клиенте, различные энчанты форм и картинок + не особо нужные виджеты такие как чаты, ajax голосовалки, «загрузка статьи из читать дальше». Ни для чего больше js не подходит на обычном сайте.
Для веб-приложений(емейл клиенты, админки ЦМС и т.п.) подход «все на javascript» идеален. SEO важно и совсем не нужено, у клиента все крутится быстро и красиво и без лишних затрат.
О, вы говорите как раз о том моменте, когда мы, сделав JavaScript-RIA поняли, что он не предназначен для таких «богатых» вещей, как анимация, навороченный User eXperience и так далее. И поняли, что надо использовать специально созданные для этого технологии (Flex).
Хотя речь в статье идет не о способах реализации, а о архитектуре. Что ж, первое, что хотелось бы сказать, так это то, что «смешивание логики и интерфейсов» не говорит об использовании клиент-серверной или не-клиент-серверной архитектуры. Оно говорит о верном или неверном использовании, скажем, паттернов или приемов по развызыванию компонентов. Мысль о независимости и переносимости бизнес-логики верная. Но вот между моделью (бизнес-логикой) и интерфейсами существует как минимум односторонняя связь (модель не знает об интерфейсе, о конкретной реализации, но конкретная реализация знает о модели и привязана к ней). И от модели внутри интерфейса никуда не деться.
Далее. Веб-сервер вполне себе может отдавать HTML-код. Почему нет? Другое дело, что можно это (как мы и делали) логически отделять от обработки самой логики. хтмл отдается точно также как, скажем Flash-ролик или Silverlight-приложение. По кусочкам или целиком — не столь важно, зависит от проекта.
Но кроме всего прочего, что интересно, HTML дает бОльшую гибкость во многих моментах.
Представим ситуацию. Мы загружаем веб-страничку с JavaScript-скриптом, который сразу после загрузки обращается к серверу за данными, получает их и отображает. Вроде нормальное поведение клиентского приложения. НО! Почему бы этой страничке еще «будучи на сервере» не попросить у этого же сервера первичные данные? Часто это будет оптимальнее и это одна из фич веб-страничек.
Зачем отдавать на обработку клиенту то, что не влияет на производительность сервера, используя все мощи паттернов, кэширования и других приемов оптимизации структуры и производительности.
Снова встает вопрос о смешивании логики интерфейсов и бизнес-логики? Нет, не должен бы вставать. Правильно стройте архитектуру (используйте, допустим, MVC). Считаю, что физическое распределение кусков системы (клиент, сервер) никак не влияет в общем смысле на оптимальность структуры конечного решения.
Хотя речь в статье идет не о способах реализации, а о архитектуре. Что ж, первое, что хотелось бы сказать, так это то, что «смешивание логики и интерфейсов» не говорит об использовании клиент-серверной или не-клиент-серверной архитектуры. Оно говорит о верном или неверном использовании, скажем, паттернов или приемов по развызыванию компонентов. Мысль о независимости и переносимости бизнес-логики верная. Но вот между моделью (бизнес-логикой) и интерфейсами существует как минимум односторонняя связь (модель не знает об интерфейсе, о конкретной реализации, но конкретная реализация знает о модели и привязана к ней). И от модели внутри интерфейса никуда не деться.
Далее. Веб-сервер вполне себе может отдавать HTML-код. Почему нет? Другое дело, что можно это (как мы и делали) логически отделять от обработки самой логики. хтмл отдается точно также как, скажем Flash-ролик или Silverlight-приложение. По кусочкам или целиком — не столь важно, зависит от проекта.
Но кроме всего прочего, что интересно, HTML дает бОльшую гибкость во многих моментах.
Представим ситуацию. Мы загружаем веб-страничку с JavaScript-скриптом, который сразу после загрузки обращается к серверу за данными, получает их и отображает. Вроде нормальное поведение клиентского приложения. НО! Почему бы этой страничке еще «будучи на сервере» не попросить у этого же сервера первичные данные? Часто это будет оптимальнее и это одна из фич веб-страничек.
Зачем отдавать на обработку клиенту то, что не влияет на производительность сервера, используя все мощи паттернов, кэширования и других приемов оптимизации структуры и производительности.
Снова встает вопрос о смешивании логики интерфейсов и бизнес-логики? Нет, не должен бы вставать. Правильно стройте архитектуру (используйте, допустим, MVC). Считаю, что физическое распределение кусков системы (клиент, сервер) никак не влияет в общем смысле на оптимальность структуры конечного решения.
Соглашусь. Автор не совсем верно понимает модель «клиент-сервер» применительно к веб-приложению. В веб-приложении клиентом выступает не машина пользователя отдельно, а связка «машина пользователя + серверная прокся между клиентом и бизнес-логикой».
Попробую пояснить на пальцах:
на примере PHP:
бизнес-логика это: БД + скрипты, взаимодействующие (CRUD) с БД (Model)
клиент это: скрипты, получающие запросы от клиента и запускающие некие бизнес процесы (Controller) + скрипты, получающие от контроллера информацию, преобразующие её и выдающие пользователю (View) + «клиенты View» (умеющие читать и показывать пользователю информацию, а также дающие ему рычаги инициации бизнес-процессов).
Всё, что «нового» придумал автор — это отказ во View от преобразования данных из модели в html. Он её преобразует в json. И там, на его стороне уже стоит не просто браузер (который умеет читать и показывать html), но браузер с его javascript-ом/flash-ем/и т.д. и т.п. (который умеет читать и показывать его json).
Попробую пояснить на пальцах:
на примере PHP:
бизнес-логика это: БД + скрипты, взаимодействующие (CRUD) с БД (Model)
клиент это: скрипты, получающие запросы от клиента и запускающие некие бизнес процесы (Controller) + скрипты, получающие от контроллера информацию, преобразующие её и выдающие пользователю (View) + «клиенты View» (умеющие читать и показывать пользователю информацию, а также дающие ему рычаги инициации бизнес-процессов).
Всё, что «нового» придумал автор — это отказ во View от преобразования данных из модели в html. Он её преобразует в json. И там, на его стороне уже стоит не просто браузер (который умеет читать и показывать html), но браузер с его javascript-ом/flash-ем/и т.д. и т.п. (который умеет читать и показывать его json).
Полностью поддерживаю! Я, кстати, понял без объяснения, по первому предложению :)
Вот я как раз (в случае с HTML) ЗА то, чтобы использовать этот вебовский «размазанный по сети» View себе во благо.
Кстати, даже в случае с Flash или Silverlight — перед отдачей приложений клиенту их можно инициализировать отчатсти на сервере, передать нужные стартовые параметры или даже собрать в соответствии с полномочиями пользователя. И я бы тоже считал эту серверную часть в определенном роде «клиентом».
Вот я как раз (в случае с HTML) ЗА то, чтобы использовать этот вебовский «размазанный по сети» View себе во благо.
Кстати, даже в случае с Flash или Silverlight — перед отдачей приложений клиенту их можно инициализировать отчатсти на сервере, передать нужные стартовые параметры или даже собрать в соответствии с полномочиями пользователя. И я бы тоже считал эту серверную часть в определенном роде «клиентом».
Кстати, у Microsoft Live Labs был проект (сейчас почему-то сайт закрыт, как пишут — временно) — Volta.
Так вот, суть в том, чтобы создавать приложение, решать прикладную задачу, с возможностью ПОТОМ разнести части приложения по серверам/клиентам, как это будет оптимально в конкретной среде, инфраструктуре. Идея очень крутая, надеюсь, ее разовьют как следует в будущем.
Так вот, суть в том, чтобы создавать приложение, решать прикладную задачу, с возможностью ПОТОМ разнести части приложения по серверам/клиентам, как это будет оптимально в конкретной среде, инфраструктуре. Идея очень крутая, надеюсь, ее разовьют как следует в будущем.
хм… привольно )) я уже года 2 занимаюсь подобной концепцией ))
очень было интересно прочитать другой взгляд на эту идею ))
очень было интересно прочитать другой взгляд на эту идею ))
Довольно интересно, но может или что-то не так понял или не достаточно вник, но напомнило то что предоставляет Appcelerator. По крайней мере серверная часть, в виде сервисов, и клиентская, в виде единой библиотеки управляющей и отправкой приемом сообщений, и локализацией, и тд там реализованы.
У меня уже очень давно подобные идеи назревали, а Вы их очень четко формализовали. Спасибо. Очень интересно узнать технические подробности. Буду с нетерпением ждать продолжения.
Вот кстати пример: W1 здесь используются почти все концепции, который вы описали. САМОЕ главное ни единой строчки HTML не генерируется на сервере.
На мой взгляд, это очень тонкая архитектура. Если что-то где сломалось или что то где-то не до получилось сайт не будет работать. Конечно такое бывает редко но это его слабость.
Как мне показалось в данной системе будет много различный идентификаторов хтмл элементов и сервер это тоже должен понимать потому что он выдает информацию что куда кидать и как это модифицировать. и это тоже на мой взгляд слабость данной машины
И, помойму, смысл кнопки обновить страницу пропадет, так как мы не можем это все обновить. или можем?
посути разработка таких приложений может снизить нагрузку с сервера и повысить нагрузку на клиента и на программистов. а вот только на сколько? и при этом не будет ли сервер делать лишних телодвижений?
Как мне показалось в данной системе будет много различный идентификаторов хтмл элементов и сервер это тоже должен понимать потому что он выдает информацию что куда кидать и как это модифицировать. и это тоже на мой взгляд слабость данной машины
И, помойму, смысл кнопки обновить страницу пропадет, так как мы не можем это все обновить. или можем?
посути разработка таких приложений может снизить нагрузку с сервера и повысить нагрузку на клиента и на программистов. а вот только на сколько? и при этом не будет ли сервер делать лишних телодвижений?
Один из плюсов такой архитектуры — очень легко и быстро сделать автоматическое тестирование. Как для пользовательского интерфейса, так и для сервисов.
поясните мысль, пожалуйста. в каком случае трудно будет сделать автоматическое тестирование?
Под тестированием подразумевается функциональное (тестирование корректной работы интерфейса) и unit-тестирование. Легкость и быстрота — создание как системы тестирования (как правило одним Php/Perl/J-Unitom, Mercury или Selenium'ом дело не обходится), так и самих тестов.
Конкретный случай — тестирование интерфейса по предопределенным данным. В случае сервисной модели (как описано в статье) в тесте указывается конкретный XML/JSON/Yaml/..., в случае генерации контента сервером — необходимо определять шаблонные переменные. И наоборот, в случае тестирования корректно сгенерированных данных — сравнение сгенерированного ответа с ожидаемым и проверка заполненность соответствующих шаблонных переменных.
Конкретный случай — тестирование интерфейса по предопределенным данным. В случае сервисной модели (как описано в статье) в тесте указывается конкретный XML/JSON/Yaml/..., в случае генерации контента сервером — необходимо определять шаблонные переменные. И наоборот, в случае тестирования корректно сгенерированных данных — сравнение сгенерированного ответа с ожидаемым и проверка заполненность соответствующих шаблонных переменных.
j-php-и другим юнитам должно быть по барабану куда и в чем отдается. потому что тестировать ими надо не front-end, а бизнес логику. меркурями и тесткомплитами тестируется клиент, который так или иначе связан с html — здесь разницы нет.
я не вижу ничего нового в топике — все это доступно даже на интуитивном уровне, правда возведено в абсолют. что касается тестирования, то в данном подходе вы просто имеете возможность отступить на один шаг к клиенту. но чем это проще — не понимаю, поэтому и спросил.
я не вижу ничего нового в топике — все это доступно даже на интуитивном уровне, правда возведено в абсолют. что касается тестирования, то в данном подходе вы просто имеете возможность отступить на один шаг к клиенту. но чем это проще — не понимаю, поэтому и спросил.
Согласен с мнением про топик).
С тестированием же — может кому и достаточно тестирования _только_ на уровне одного компонента (серверная или клиентская часть), но вот кому-то в добавок требуется отслеживать корректный обмен данными между компонентами. Например, отлов бага с выводом — косяк в шаблоне или в вызываемом методе слоя view?
С тестированием же — может кому и достаточно тестирования _только_ на уровне одного компонента (серверная или клиентская часть), но вот кому-то в добавок требуется отслеживать корректный обмен данными между компонентами. Например, отлов бага с выводом — косяк в шаблоне или в вызываемом методе слоя view?
до «Здесь я опишу его структуру.» пропустил — философия не связанная ничем.
с удовольствием почитал про совершенный аякс.
а вот про размышления об архитектуре и что где должно генерится — это уже по месте лучше смотреть, а не абстрактно философствовать. сам аякс тоже не появится — первоначально кто-то должен его отдать. в том числе и в html виде.
к тому же правильно отделив представление от логики на сервере, подобных неудобств в отсутствии webservice-only интерфейсов не замечаешь.
о, забыл один момент — я же пошел посмотреть, чем гордится автор. хотел увидеть совершенный аякс. и таки ничего не нашел. где сервисы? где «никакого html в ответе»? :) вот это — "<h1>Length Required</h1>"?
я это к тому, что если автор говорит о теории, о очень хочется увидеть что он на этой почве смог достигнуть.
с удовольствием почитал про совершенный аякс.
а вот про размышления об архитектуре и что где должно генерится — это уже по месте лучше смотреть, а не абстрактно философствовать. сам аякс тоже не появится — первоначально кто-то должен его отдать. в том числе и в html виде.
к тому же правильно отделив представление от логики на сервере, подобных неудобств в отсутствии webservice-only интерфейсов не замечаешь.
о, забыл один момент — я же пошел посмотреть, чем гордится автор. хотел увидеть совершенный аякс. и таки ничего не нашел. где сервисы? где «никакого html в ответе»? :) вот это — "<h1>Length Required</h1>"?
я это к тому, что если автор говорит о теории, о очень хочется увидеть что он на этой почве смог достигнуть.
Я какраз занимаюсь такими приложениями :) Сеичас активно разрабатываю свой Объектный API (White API) на Prototype для построения формы приложения и реализации клиентской логики, буду писать адаптеры для плагинов прототайпа и jQuery. Весь вид генерится JavaScript'ом(с помошью билдера или ручками через new), облагораживается CSSом + JS. Элементы располагаются по дефалту абсолютно в пикселях.
Плюс ко всему разрабатываю «Интегрированную браузерную среду для разработки веб-приложений приложений» поколения 2.0 (White RAD IDE 2).
Разработка IDE уже близится к концу надеюсь к Новому Году выпустить альфу-бету-релизКандидит. Поддерживаемые IDE браузеры (Ff IE7+ Op Sa)
Рабочая версия White RAD IDE 2
Тщедушные примеры того, что пока умеет:
Тестовый пример прошлой недели (из-за бага открывается только в FF; да URL него гигантский просто это формат передачи данных из окна дизайна к окну дабага/просмотра, в рабочей версии такого урла не будет)
Маааленький пример (Ff IE Op Sa)
Плюс ко всему разрабатываю «Интегрированную браузерную среду для разработки веб-приложений приложений» поколения 2.0 (White RAD IDE 2).
Разработка IDE уже близится к концу надеюсь к Новому Году выпустить альфу-бету-релизКандидит. Поддерживаемые IDE браузеры (Ff IE7+ Op Sa)
Рабочая версия White RAD IDE 2
Тщедушные примеры того, что пока умеет:
Тестовый пример прошлой недели (из-за бага открывается только в FF; да URL него гигантский просто это формат передачи данных из окна дизайна к окну дабага/просмотра, в рабочей версии такого урла не будет)
Маааленький пример (Ff IE Op Sa)
Где-то в районе серверного JavaScript вы меня потеряли. Было бы здорово, если бы раскрывалась тема стоимости такой разработки, потому что в том виде как вы это все описали ощущение что это уже не распределенная система (n-tier), а размазанная по всему, чему только можно. С точки зрения нагрузки на сервер — безусловно, ура, сервер больше не стонет от унижения что ему приходится рендерить HTML. С точки зрения разработки и поддержки всего этого «тонкого эфира» — мне кажется будет больше мороки. Возможно для какой-нибудь крупной и богатой организации это и будет иметь смысл, но «в среднем по больнице» имхо дороговато выйдет.
Я довно такое придумал.
Как-то вы на свой лад дали определение «клиент-сервер» приложений. Чем HTML не ответ на запрос?
Слишком уж сложные узлы архитектуры у вас получились, контролы на JS,… а почему не XSLT?
Вашей архитектурой вы пытаетесь отделить бизнес-логику приложения перенести на сервер, и тут нечего спорить, MVC рулит. Но, тем самым вы породили еще один слой логики (HTML — JS — WebServices) который опять же рулится на клиенте. Вот как раз это и есть «слабое звено» вашей архитектуры.
Слишком уж сложные узлы архитектуры у вас получились, контролы на JS,… а почему не XSLT?
Вашей архитектурой вы пытаетесь отделить бизнес-логику приложения перенести на сервер, и тут нечего спорить, MVC рулит. Но, тем самым вы породили еще один слой логики (HTML — JS — WebServices) который опять же рулится на клиенте. Вот как раз это и есть «слабое звено» вашей архитектуры.
Чем плохи толстые клиенты? и чем gmail последней версии плох? :)
ммм тут же речь не про «толстяков». Gmail — всетаки хорош наверно. Но gwt технология меня совсем не впечатлила, даже разочаровала. Свингерам наверно будет проще, писать на gwt, но сама архитектура это технологии мне совсем не понравилась(может я недостаточно углубился в ее изучении). Все вперемешку модель-вью-контроллер.
Ну XSLT то, кстати, ни при чем. Это только один из шаблонизаторов (хороший, кстати, и еще стандартизированный). Суть в том, что с любым шаблонизатором при грамотном использовании и грамотной архитектуре можно сделать круто. Про MVC вы совершенно правы, странно что еще не все матерые веб-разработчики его используют, хотя паттерну уже пара десятков лет точно.
А вот про «слабое звено» — это не так, опять же все зависит от того, как сделано. Это не плохая архитектура, ибо клиентская часть так или иначе будет зависеть от логики, а в прямой передаче данных ничего «эдакого» нету.
А вот про «слабое звено» — это не так, опять же все зависит от того, как сделано. Это не плохая архитектура, ибо клиентская часть так или иначе будет зависеть от логики, а в прямой передаче данных ничего «эдакого» нету.
www.w3.org/TR/xslt
с XSLT конечно много ограничений, но зато вы вынесите логику JS на xslt. Вот это уже интереснее.
Здрасте, «клиентская часть так или иначе будет зависеть от логики» вы же как раз от этого и пытаетесь уйти. А получилось все наоборот, давайте начнем с того — что такое вью? и какая роль у JS в вью слое? разве это не логика некоего нового слоя «вью-модель» даже больше «вью-модель-контроллер»?
с XSLT конечно много ограничений, но зато вы вынесите логику JS на xslt. Вот это уже интереснее.
Здрасте, «клиентская часть так или иначе будет зависеть от логики» вы же как раз от этого и пытаетесь уйти. А получилось все наоборот, давайте начнем с того — что такое вью? и какая роль у JS в вью слое? разве это не логика некоего нового слоя «вью-модель» даже больше «вью-модель-контроллер»?
всё верно. JS — это новый слой MVC на стороне браузера.
В javascript в браузере:
Model — это данные, сохранённые в хэшах + данные из DOM + скрипты, работающие с этими данными
View — это скрипты, осуществляющие манипуляции с CSS и DOM
Controller — это скрипты, вешающие хэндлеры событий и дёргающие Model на предмет данных и View на предмет отображения
Когда модели в JS не хватает локальных данных, или она «чувствует», что данные устарели, она дёргает веб-сервер. Т.е. становится клиентом для приложения веб-сервера (Apache, IIS и др.). При этом в самом веб-сервере происходит ещё несколько связей типа клиент-сервер. Например: Apache запускает PHP скрипты и получает от них то, что нужно выдать клиенту (Apache — клиент ПХП скрипта). PHP скрипт дёргает базу и получает из неё инфу (PHP — клиент СУБД)
При этом в самом PHP опять же несколько уровней «клиент-сервер»: есть скрипты-модели, дёргающие базы, а есть скрипты-контроллеры, дёргающие эти скрипты (контроллер стал клиентом для модели). вью может дёргать контроллер на предмет необходимости дополнительных данных (вью стал клиентом контроллера) и т.д.
Что самое смешное в этой ситуации, что общение браузера (IE, Firefox, Opera) с веб-сервером (Apache, IIS) тоже происходит по модели «клиент-сервер» и это сбивает новичков с толку — все без исключения полагают, что в веб-приложении «клиент» — это браузер с его движком рендеринга и скриптинга, а «сервер» — это связка apache+php+mysql. То, что модель клиент-сервер в веб-приложении находится на более высоком уровне — догадываются немногие. Отсюда и заявления по типу:
«Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом… „
В javascript в браузере:
Model — это данные, сохранённые в хэшах + данные из DOM + скрипты, работающие с этими данными
View — это скрипты, осуществляющие манипуляции с CSS и DOM
Controller — это скрипты, вешающие хэндлеры событий и дёргающие Model на предмет данных и View на предмет отображения
Когда модели в JS не хватает локальных данных, или она «чувствует», что данные устарели, она дёргает веб-сервер. Т.е. становится клиентом для приложения веб-сервера (Apache, IIS и др.). При этом в самом веб-сервере происходит ещё несколько связей типа клиент-сервер. Например: Apache запускает PHP скрипты и получает от них то, что нужно выдать клиенту (Apache — клиент ПХП скрипта). PHP скрипт дёргает базу и получает из неё инфу (PHP — клиент СУБД)
При этом в самом PHP опять же несколько уровней «клиент-сервер»: есть скрипты-модели, дёргающие базы, а есть скрипты-контроллеры, дёргающие эти скрипты (контроллер стал клиентом для модели). вью может дёргать контроллер на предмет необходимости дополнительных данных (вью стал клиентом контроллера) и т.д.
Что самое смешное в этой ситуации, что общение браузера (IE, Firefox, Opera) с веб-сервером (Apache, IIS) тоже происходит по модели «клиент-сервер» и это сбивает новичков с толку — все без исключения полагают, что в веб-приложении «клиент» — это браузер с его движком рендеринга и скриптинга, а «сервер» — это связка apache+php+mysql. То, что модель клиент-сервер в веб-приложении находится на более высоком уровне — догадываются немногие. Отсюда и заявления по типу:
«Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом… „
Вы меня не совсем верно поняли. Я тут не спорю на эту тему, точнее не оспариваю вашу точку зрения :) Просто дополняю и описываю свое видение.
Да, совершенно верно, XSLT (как и любой другой шаблонизатор) отвечает за «логику представления» (View Logic). Эту же роль можно взвалить и на JS (частично или полностью). Но я за то, что в «True Web App» использовать как раз шаблонизатор, а JS оставить его роль, балансируя между ролью клиента и ролью сервера в формировании View.
Насчет MVC на клиенте вы совершенно правы — как в архитектуре всего приложения есть MVC, так есть эдакое «маленькое MVC» чисто на клиенте, в JavaScript'е, если хотите (стремление к разделению всех видов логики привело, например, к XForms). Но это вовсе не означает, что мы должны выбирать, какой из этих «MVC» использовать — считаю, что использовать надо оба по мере необходимости.
Да, совершенно верно, XSLT (как и любой другой шаблонизатор) отвечает за «логику представления» (View Logic). Эту же роль можно взвалить и на JS (частично или полностью). Но я за то, что в «True Web App» использовать как раз шаблонизатор, а JS оставить его роль, балансируя между ролью клиента и ролью сервера в формировании View.
Насчет MVC на клиенте вы совершенно правы — как в архитектуре всего приложения есть MVC, так есть эдакое «маленькое MVC» чисто на клиенте, в JavaScript'е, если хотите (стремление к разделению всех видов логики привело, например, к XForms). Но это вовсе не означает, что мы должны выбирать, какой из этих «MVC» использовать — считаю, что использовать надо оба по мере необходимости.
Да, вдобавок,
«но зато вы вынесите логику JS на xslt»
Мы можем перенести только логику формирования View, а не весь функционал JS (анимация, обработка клиентских событий). И я ЗА такой подход в веб-приложении. Если же «хочется большего» — считаю, что это повод смотреть в сторону pure-RIA (Flex, Silverlight, JavaFX).
«но зато вы вынесите логику JS на xslt»
Мы можем перенести только логику формирования View, а не весь функционал JS (анимация, обработка клиентских событий). И я ЗА такой подход в веб-приложении. Если же «хочется большего» — считаю, что это повод смотреть в сторону pure-RIA (Flex, Silverlight, JavaFX).
По-моему не очень разумно выносить много логики на яваскрипт (в т.ч. логику по рендерингу хтмл), по той просто причине что яваскрипт не является компилируемым языком, отсюда проблемы в отладке, поддержке и т д.
Аргумент в пользу уменьшения нагрузки на веб сервер тоже весьма спорный, убирая логику рендеринга с севера вы нагружаете клиент, хорошо ли это? А что если у пользователя отключен джаваскрипт, что он увидит у себя на экране?
В последнее время просматривается тенденция вынесения в яваскрипт как можно большей функциональности, по сути сократив функции веб-сервера до источника данных и хранения сессии. Как то это неправильно на мой взгляд…
Аргумент в пользу уменьшения нагрузки на веб сервер тоже весьма спорный, убирая логику рендеринга с севера вы нагружаете клиент, хорошо ли это? А что если у пользователя отключен джаваскрипт, что он увидит у себя на экране?
В последнее время просматривается тенденция вынесения в яваскрипт как можно большей функциональности, по сути сократив функции веб-сервера до источника данных и хранения сессии. Как то это неправильно на мой взгляд…
Могу лишь напомнить, речь идет о веб-приложениях, а не о простых сайтах. Не забывайте.
и что если это веб приложение, то значит в нём должно быть очень много яваскрипта?
Не совсем. Обычно они предполагают Богатый юзерский интерфейс, часто делают яваскрипт обязательным для клиентов и предназначены не для того, чтобы юзер читал там новости или другой контент, а именно работал там. Следовательно ему должно быть удобно работать(поменьше перегружать страницу, быстро получать данные, иногда большого обьема и быстро же их смотреть). Таким «сайтам» наплевать, что думают о них поисковики, и т.д. и т.п. отличий много.
Практически любой веб сайт кроме статического HTML является веб-приложением (web application). Ну и что?
Проблемы с отладкой и поддержкой яваскрипта такие же как и с любым серверым языком.
Около 95% всех пользователей используют javascript. Если идет речь о десктопном решении, то такой сервис на толстых клиентах самое то. Даже мобильные платформы деражт js.
Нагрузка на сервер уменьшается это точно. Теперь все тянет только СУБД + пара статических файлов. Нагружать клиент сеичас хорошо т.к. мощности компьютеров растут, все браузеры становятся все лучше и быстрее. Уменьшается объем трафика в разы → клиент не ждет.
> сократив функции веб-сервера до источника данных и хранения сессии
Просто это такой подход и у него такие запросы.
Около 95% всех пользователей используют javascript. Если идет речь о десктопном решении, то такой сервис на толстых клиентах самое то. Даже мобильные платформы деражт js.
Нагрузка на сервер уменьшается это точно. Теперь все тянет только СУБД + пара статических файлов. Нагружать клиент сеичас хорошо т.к. мощности компьютеров растут, все браузеры становятся все лучше и быстрее. Уменьшается объем трафика в разы → клиент не ждет.
> сократив функции веб-сервера до источника данных и хранения сессии
Просто это такой подход и у него такие запросы.
всё красиво, но больно уж хлипенько. можно использовать xslt и параллельно будет, где отрисовывать вьюху. но вот писать толстый клиент под каждый браузер, боже упаси.
Чтобы конкретнее говорить о самой технологии «Соевершенный Ajax», стоит дождаться второй части, где уже будут «технические детали». Так что стоит обсуждать только «первую половину первой части» =)
Итак, приступим.
Во-первых, давайте возьмем некое «истинное» клиент-серверное приложение, например некоторый IM.
Что мы там имеем? Все отображение «вшито» в клиент, он общается с клиентом по некоторому протоколу (XMPP, OSCAR и т.д.) и «получает голые» данные и сам решает как их отображать.
Теперь возьмем Браузер. Он требует, чтобы ему кроме данных, передали то, КАК отображать интерфейс, это, если хотите, — Универсальный клиент. Кстати, кроме ХТМЛ есть еще XUL, например.
Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера). А вот чтобы не смешивать, надо использовать, как было сказано, паттерны (MVC, например). Ну, а про XML+XSL я вообще молчу.
И в заключение.
1) Веб браузер является клиентом, никаких противоречий тут нет
2) У веб браузера своя специфика направленная на универсальность
3) Веб браузер требует, чтобы сервер обяснил как ему отображать данные.
4) Проблем с поддержкой сервером разнык клиентов нет
Итак, приступим.
Во-первых, давайте возьмем некое «истинное» клиент-серверное приложение, например некоторый IM.
Что мы там имеем? Все отображение «вшито» в клиент, он общается с клиентом по некоторому протоколу (XMPP, OSCAR и т.д.) и «получает голые» данные и сам решает как их отображать.
Теперь возьмем Браузер. Он требует, чтобы ему кроме данных, передали то, КАК отображать интерфейс, это, если хотите, — Универсальный клиент. Кстати, кроме ХТМЛ есть еще XUL, например.
Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера). А вот чтобы не смешивать, надо использовать, как было сказано, паттерны (MVC, например). Ну, а про XML+XSL я вообще молчу.
И в заключение.
1) Веб браузер является клиентом, никаких противоречий тут нет
2) У веб браузера своя специфика направленная на универсальность
3) Веб браузер требует, чтобы сервер обяснил как ему отображать данные.
4) Проблем с поддержкой сервером разнык клиентов нет
У вас и у автора немного разные понятия клиента. Для автора клиентом является приложение, способоное работать с конкретной задачей, браузер выступает в качестве движка рендера пользовательского интерфеса, движка для скриптового языка и реализацией чистого http(s), а у вас это универсальный клиент для отображения html+css+js… Подход описанный в статье ни в коем случае не претендует на универсальность! Это нишевый подход для построения RIA приложений, использующий стандарты.
Пожалуйста, не привязывайтесь только к HTML и иже. Я как-то говорил и повторю, что для меня главным для RIA приложения считается протокол, а не его реализация в конкретном клиенте. В вашем примере с IM можно красиво провести аналогию: есть ОДИН протокол и много клиентов, какие-то онлайновые, скажем, написаные на флеше, какие-то написаны только под Линукс, что-то под Мак и т.д.
>> Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера).
В виде статики, во-первых. Во-вторых приложение очень легко и просто сделать локальным в полном смысле этого слова с помощью MozillaPrizm к примеру. В-третьих, при открытости протокола достаточно просто писать любые клиенты, какие вам угодно, хоть на Бейсике под ДотНет, хоть на ObjC под IPhone.
Пожалуйста, не привязывайтесь только к HTML и иже. Я как-то говорил и повторю, что для меня главным для RIA приложения считается протокол, а не его реализация в конкретном клиенте. В вашем примере с IM можно красиво провести аналогию: есть ОДИН протокол и много клиентов, какие-то онлайновые, скажем, написаные на флеше, какие-то написаны только под Линукс, что-то под Мак и т.д.
>> Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера).
В виде статики, во-первых. Во-вторых приложение очень легко и просто сделать локальным в полном смысле этого слова с помощью MozillaPrizm к примеру. В-третьих, при открытости протокола достаточно просто писать любые клиенты, какие вам угодно, хоть на Бейсике под ДотНет, хоть на ObjC под IPhone.
Иконки приятные
Молодец, Алик!
Статья понравилась. Интересна производительность всего этого дела по сравнению со стандартным подходом. Бысрее, медленнее, есть ли кака-нибудь статистика?
Не думаю, что производительность отличается в разы.
Выигрышь будет в представлении данных (json / html)
Тут вопрос о том, что быстрее json_encode или шаблонизатор на том же объеме данных.
Для json решения ещё
— Значительно уменьшается объем кэша страниц.
— Значительно уменьшается объем трафика.
Из дополнительных плюсов json:
— В случае чего не надо парсить данные из html все и так открыто =) Как следствие множество клиентов для одного сервиса.
Выигрышь будет в представлении данных (json / html)
Тут вопрос о том, что быстрее json_encode или шаблонизатор на том же объеме данных.
Для json решения ещё
— Значительно уменьшается объем кэша страниц.
— Значительно уменьшается объем трафика.
Из дополнительных плюсов json:
— В случае чего не надо парсить данные из html все и так открыто =) Как следствие множество клиентов для одного сервиса.
Я как-то не уловил разницы с филосифией того же ExtJs кроме допонительного звена «семантическая верстка», которое так и не понял зачем нужно.
Порпавьте, если я неправильно понял.
1. Получаем данные от сервера
2. На основании этих данных генерируем на клиенте html и вставляем в документ
3. Применяем к этой разметке создание контролов
Почему бы не пропустить ворой пункт и не генерировать контрол на основании данных?
Порпавьте, если я неправильно понял.
1. Получаем данные от сервера
2. На основании этих данных генерируем на клиенте html и вставляем в документ
3. Применяем к этой разметке создание контролов
Почему бы не пропустить ворой пункт и не генерировать контрол на основании данных?
Всё верно. У ExtJS именно такая идеология и есть. Только они не указывают, что сервер должен быть Mozilla Rhino, что нужно использовать ORM и т.п. Им вообще всё равно, что там делает сервер — лишь бы данные отдавал. А автор просто смешал всё в кучу и выдал это за «Совершенный AJAX».
Если уж на то пошло, то AJAX вообще никакого отношения не имеет ни к базе данных, ни к серверной платформе, ни к отображению/генерации контролов
Если уж на то пошло, то AJAX вообще никакого отношения не имеет ни к базе данных, ни к серверной платформе, ни к отображению/генерации контролов
фактически приведен подход к чистой архитектуре клиент-сервер, применяемой в распределенных, ресурсоемких ERP-системах, типа SAP ERP.
Сервер БД (собственно, база)
Аппликейшн сервер (один или несколько — собственно обработка бизнес-логики)
ГУИ (пользовательский интерфейс).
Развивая идею: бизнес-логика хранится в БД. Детали интерфейса хранятся в БД.
Аппликейшн сервер- вычисления, выбор из БД, передача инфы от пользователя и к пользователю.
ГУИ — отображение всего и вся (и не более).
ГУИ- набор методов для отображение разных объектов, обладающих определенными свойствами. Объекты передаются аппликейшном после выборки из БД и определенной обработки.
Сервер БД (собственно, база)
Аппликейшн сервер (один или несколько — собственно обработка бизнес-логики)
ГУИ (пользовательский интерфейс).
Развивая идею: бизнес-логика хранится в БД. Детали интерфейса хранятся в БД.
Аппликейшн сервер- вычисления, выбор из БД, передача инфы от пользователя и к пользователю.
ГУИ — отображение всего и вся (и не более).
ГУИ- набор методов для отображение разных объектов, обладающих определенными свойствами. Объекты передаются аппликейшном после выборки из БД и определенной обработки.
Автору «респект и уважуха». Не столько даже за саму статью, сколько за применении описаных принципов на практике. Многие любят рассуждать на подобные темы, но когда доходит до практики…
."… Полностью отказаться от использования сервера для реализации пользовательского интерфейса web-приложений..."
Как то это совсем не модно, в свете нынешних тенденций… Облачные вычисления, то да се ;)
Как то это совсем не модно, в свете нынешних тенденций… Облачные вычисления, то да се ;)
забавно, я как раз на аналогичных принципах строю свое новое приложение :)
Прочитал вместе со всеми комментариями. Так и не понял, зачем огород городить. Не понятно в чём выигрыш. Технологии развиваются довольно логично. Нужны богатые клиентские приложения — появляется Flex. 90% того, что можно было выжать из ява-скрипта (по-моему) выжали в ExtJS. Генераторы JS на разных серверных языках тоже плодятся как грибы, чтоб не писать ни одной строчки на JS вообще (видимо подход, обратный вашему). Если вам и того и другого недостаточно, то пора писать свои клиенты на той же Яве, а не мучить браузер.
Ну и маленькая добавочка. Вы там пишите, что не испольуете особенностей конкретной БД. Как раз сегодня с колегой дискутировал на подобную тему, только относительно языков. Универсальность — это конечно здорово, но в большинстве случаев не используя преимущество той или иной базы или языка вы затрудняете сами себе разработку и, в большенстве случаев, колечите производительность.
Ну и маленькая добавочка. Вы там пишите, что не испольуете особенностей конкретной БД. Как раз сегодня с колегой дискутировал на подобную тему, только относительно языков. Универсальность — это конечно здорово, но в большинстве случаев не используя преимущество той или иной базы или языка вы затрудняете сами себе разработку и, в большенстве случаев, колечите производительность.
Про технологии — преимущества все-таки есть. Такое чувствуешь, когда плотно занимаешься этим вопросом.
Про БД — полностью +1. Универсализм и производительность всегда на разных концах. Я никак нормально не смог сделать так, чтобы и ораклисты не плевались и чтобы на mysql можно было бы разрабатывать.
Про БД — полностью +1. Универсализм и производительность всегда на разных концах. Я никак нормально не смог сделать так, чтобы и ораклисты не плевались и чтобы на mysql можно было бы разрабатывать.
Я так понял что формировать html-каркас приложения на сервере — это типа не круто=)
Давайте тогда сразу будем предоставлять просто доступ к базе данных только на чтение,
а народ пусть как хочет так и формирует представление. Так вообще полная свобода и все в восторге.
На самом деле вот maps.google.ru первый попавшийся «здоровый» пример описанной выше технологии (ну там выводится со старта пару див-ов, но, я надеюсь, это не смертельно) и никто не бегает, не кричит про переворот в мире веб=)
Кстати ждем от Вас реализаций в подкрепление теории.
Еще интересно про Rhino будет почитать=)
Давайте тогда сразу будем предоставлять просто доступ к базе данных только на чтение,
а народ пусть как хочет так и формирует представление. Так вообще полная свобода и все в восторге.
На самом деле вот maps.google.ru первый попавшийся «здоровый» пример описанной выше технологии (ну там выводится со старта пару див-ов, но, я надеюсь, это не смертельно) и никто не бегает, не кричит про переворот в мире веб=)
Кстати ждем от Вас реализаций в подкрепление теории.
Еще интересно про Rhino будет почитать=)
Что я вижу в данном подходе: паттерн MVC, где слой V полностью вынесен на клиентский уровень и слой C распределен между клиентом и сервером. В результате чего:
+ сервер разгружается на рендеринг HTML.
– сервер дополнительно нагружается сериализацией/десериализацией запросов/ответов между JSON<-->native language constructions(PHP, JAVA, RUBY, ...) умноженно на количество запросов/ответов.
– отладка клиентского слоя усложняется в разы.
– скорость отклика клиента увеличивается за счет увеличения количества запросов на сервер.
– эта скорость падает еще в случае зависимости запроса от ответа предыдущего ибо в таком случае их невозможно слать асинхронно, должна быть последовательность.
И в чем же данная системма дает прирост? В чем заключается упрощение и большая гибкость построения интерфейсов по сравнению с любым из серверных шаблонизаторов + открытое API для неHTML клиентов или сторонних сервисов, если такие предполагаются?
+ сервер разгружается на рендеринг HTML.
– сервер дополнительно нагружается сериализацией/десериализацией запросов/ответов между JSON<-->native language constructions(PHP, JAVA, RUBY, ...) умноженно на количество запросов/ответов.
– отладка клиентского слоя усложняется в разы.
– скорость отклика клиента увеличивается за счет увеличения количества запросов на сервер.
– эта скорость падает еще в случае зависимости запроса от ответа предыдущего ибо в таком случае их невозможно слать асинхронно, должна быть последовательность.
И в чем же данная системма дает прирост? В чем заключается упрощение и большая гибкость построения интерфейсов по сравнению с любым из серверных шаблонизаторов + открытое API для неHTML клиентов или сторонних сервисов, если такие предполагаются?
А я думаю в ходе эволюции будет так:
Сервер отдает данные в формате xml. На клиенте эти данные обрабатываются при помощи соответствующей XSLT в любой формат (RSS, XHTML, PDF), а потом всё это это дело допиливается JS.
Т.е. мы получаем всегда от сервера только данные, а клиент уже решает, как их отобразить, в каком формате. Приправить все это REST'ом, получится, думаю, очень хорошо.
Осталось только ждать, когда все браузеры будут обрабатывать XSLT, и делать это одинаково.
Сервер отдает данные в формате xml. На клиенте эти данные обрабатываются при помощи соответствующей XSLT в любой формат (RSS, XHTML, PDF), а потом всё это это дело допиливается JS.
Т.е. мы получаем всегда от сервера только данные, а клиент уже решает, как их отобразить, в каком формате. Приправить все это REST'ом, получится, думаю, очень хорошо.
Осталось только ждать, когда все браузеры будут обрабатывать XSLT, и делать это одинаково.
Небольшой оффтоп.
Упорно не пускает на вашем demo4school.sintest.ru/ под учётками Завуча и Учителя. Обзывает меня undefined. Под Морковкиным всё ОК
Упорно не пускает на вашем demo4school.sintest.ru/ под учётками Завуча и Учителя. Обзывает меня undefined. Под Морковкиным всё ОК
Думал над этой концепцией, когда возникла необходимость по просьбе клиентов написать интернет-магазин работающий полностью на аяксе(:
В итоге был запущен smart.ru
Как разработчику — мне понравилась концепция, и удобство разработки мне показалось выше чем в стандартной идеологии веб-приложений.
Но все это пока очень далеко от совершенства, имхо
В итоге был запущен smart.ru
Как разработчику — мне понравилась концепция, и удобство разработки мне показалось выше чем в стандартной идеологии веб-приложений.
Но все это пока очень далеко от совершенства, имхо
Писал пол года назад об этом подходе :)
Кому интересен пример — добро пожаловать:
habrahabr.ru/blogs/javascript/28814/
Кому интересен пример — добро пожаловать:
habrahabr.ru/blogs/javascript/28814/
еще одно похабное дерьмо из серии про всё по-немножку!
/* «Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода */
Написали бы просто: «Товарищи! Используйте для отдачи даннных с сервера непременно JSON или XML!»
Впрочем, статьи разные нужны. Но называть этот подход новым?! >_<
Написали бы просто: «Товарищи! Используйте для отдачи даннных с сервера непременно JSON или XML!»
Впрочем, статьи разные нужны. Но называть этот подход новым?! >_<
Мне кажется, что чрезмерное увлечение переносом генерации html на сторону клиента чревато осложнением разработки. ИМХО, проще написать код под одну платформу и быть на 100% уверенным, что получится именно тот html, который нам нужен, чем писать js-код, хоть и стремясь к кроссплатформенности, но всё равно тестируя это на зоопарке браузеров.
Поэтому я лично стараюсь по возможности не усложнять клиентский код. Всё-таки его отладка дело куда более капризное, чем отладка серверного кода. На сервере хоть платформа одна.
Поэтому я лично стараюсь по возможности не усложнять клиентский код. Всё-таки его отладка дело куда более капризное, чем отладка серверного кода. На сервере хоть платформа одна.
tl;dr
это индексируется поисковиками?
это индексируется поисковиками?
Алик, всё клево, много букв. Но смысл где? Зачем это все?
Как-то кидал на Хабр ссылку с презентацией на подобную тему: Scala.habrahabr.ru/blog/42015/
Ничего нового не узнал, но вот на серверную реализацию посмотрел бы.
Ничего нового не узнал, но вот на серверную реализацию посмотрел бы.
К сожалению, ввы привели лишь маленький кусочек кода — поэтому понять вашу идею сложно но все же…
//Получаем с сервера объект Морковкин Вася
var objStudent1 = Sintez.getStudent («this.firstName = 'Вася' and this.secondName = 'Морковкин'»);
//Получаем объект 3 «А» класс
var objClass1 = Sintez.getClass («this.getClassNuber() = 3 and this.liter = 'А'»);
//Делаем Васю учеником этого класса
objClass1.addStudent (objStudent1);
Правилдьно ли я понимаю, что каждый вызов getStudent() генерирует AJAX-запрос? Следовтельно, чтобы выполнить какое-то действие, вам приходится делать несколько запросов? Это серьезно все замедляет для клиента, лучше бы делался один запрос и все выполнялось на быстром сервере. А если запросов 5? У меня с пингом 100-150 мс (fucking ADSL) это займет минимум секунду. А если 10?
Поясню.
1) Лишний HTTP-запрос — лишние тормоза. быстрее получить за раз 300 байт, чем 2 раза по 100. не верите — посчитайте сами с учетом пинга и скорости. Я бы вобще предпочел чтобы страница грузилась одним архивом, а не кусками как сейчас это сделано в HTTP.
2) На сервере выгоднее 1 раз проинициализироватьт приложение, сделать коннект к БД (который может занять больше времени чем само выполнение запроса), сделать 2 запроса, чем повторить все это по отдельности.
И еще. Имхо — лучше на сервере гененрировать и отдавать HTML чем городить всю эту кучу с JavaScript. Пользователям кривонаписанного фаерфокса вообще плохо, так как пока работает JS интерфейс ФФ подвисает, даже переключиться в другую вкладку нельзя. Пусть лучше трудится ваш быстрый сервер, чем мой несчастный процессор, на котором кроме браузера запущена куча приложений.
Если вы используете правильный HTML то передать данные в HTML-формате, или с вашей разметкой —разница невелика.
Вообще, с быстрым интернетом тормоза JS становятся намного чувствительнее, и важнее чем лишние 1000 байт переданные с сервера. Кроме того, если JS реализован криво, например, как отправка комментов на Хабре, работающая через раз, и при этом нельзя сделать отправку обычным POST запросом, это вообще мерзко.
//Получаем с сервера объект Морковкин Вася
var objStudent1 = Sintez.getStudent («this.firstName = 'Вася' and this.secondName = 'Морковкин'»);
//Получаем объект 3 «А» класс
var objClass1 = Sintez.getClass («this.getClassNuber() = 3 and this.liter = 'А'»);
//Делаем Васю учеником этого класса
objClass1.addStudent (objStudent1);
Правилдьно ли я понимаю, что каждый вызов getStudent() генерирует AJAX-запрос? Следовтельно, чтобы выполнить какое-то действие, вам приходится делать несколько запросов? Это серьезно все замедляет для клиента, лучше бы делался один запрос и все выполнялось на быстром сервере. А если запросов 5? У меня с пингом 100-150 мс (fucking ADSL) это займет минимум секунду. А если 10?
Поясню.
1) Лишний HTTP-запрос — лишние тормоза. быстрее получить за раз 300 байт, чем 2 раза по 100. не верите — посчитайте сами с учетом пинга и скорости. Я бы вобще предпочел чтобы страница грузилась одним архивом, а не кусками как сейчас это сделано в HTTP.
2) На сервере выгоднее 1 раз проинициализироватьт приложение, сделать коннект к БД (который может занять больше времени чем само выполнение запроса), сделать 2 запроса, чем повторить все это по отдельности.
И еще. Имхо — лучше на сервере гененрировать и отдавать HTML чем городить всю эту кучу с JavaScript. Пользователям кривонаписанного фаерфокса вообще плохо, так как пока работает JS интерфейс ФФ подвисает, даже переключиться в другую вкладку нельзя. Пусть лучше трудится ваш быстрый сервер, чем мой несчастный процессор, на котором кроме браузера запущена куча приложений.
Если вы используете правильный HTML то передать данные в HTML-формате, или с вашей разметкой —разница невелика.
Вообще, с быстрым интернетом тормоза JS становятся намного чувствительнее, и важнее чем лишние 1000 байт переданные с сервера. Кроме того, если JS реализован криво, например, как отправка комментов на Хабре, работающая через раз, и при этом нельзя сделать отправку обычным POST запросом, это вообще мерзко.
Я бы вобще предпочел чтобы страница грузилась одним архивом, а не кусками как сейчас это сделано в HTTP.
Опять же палка о двух концах: с одной стороны меньше данных передается ОДНИМ запросом, но с другой стороны невозможно параллельное выполнение рендеринга/догрузки/дорендеринга, эти все процессы можно будет начать только после того, как все данные уже получены.
По моему мнению делить на «клиента» и «сервер» по признаку географической отдалености не совсем перспективно. Как локальная сеть по сути уже не воспринимается пользователем в парадигме клиент-сервер, так уже сейчас в технологически развитых странах пользователь не различает, где находится «сервер»: в корпусе его компьютера, в соседней комнате или на соседнем материке. Разделение между клиентом и сервером происходит на уровне девелоперской парадигмы, а не там где подключаются провода. Если современные сервера берут на себя часть клиентских вычислений, по почему бы и наоборот клиенту не делать часть серверных вычислений? Совершенно нет необходимости заливать бетоном то место, где проходит эта граница.
Может если уж делать, то делать так:
1. Сервер Бизнес логики:
БД + реализация бизнесЛогики
Работа через обмен данными XML
2. Сервер ренедринга ( представления )
Обмен с [1] по XML, с клиентами — чем угодно, в случае с web — HTML / CSS / JS
Плюсы такой технологии:
1) возможности кластеризации серверов бизнес логики, либо разделения их по функционалу
2) возможность кластеризации серверов рендеринга, либо разделения их по функционалу
3) возможность кэширования документов [2]
4) возможность использования разных реализаций [1] и [2], но работающих как единое целое.
А в данном случае вы получаете очень тяжоловесную систему, во первых получить один БОЛЬШОЙ файл гораздо быстрее и легче, чем обработать 10 мелких запросов ( а я боюсь что во время интенсивной работы их у Вас будет куда больше ), вы откзываетесь от легковесных клиентов, где далеко не всегда можно использовать JS — не есть хорошо. Вы зависимы от скорости выполнения клиентских JS, т.к. инасе работа с системой превратится в нудную тягомотину.
Увы и ах — не понятны цели — ЗАЧЕМ? чтобы было так красиво все? Далеко не всегда красивое решение — это лучшее решение. К сожелению.
P.S. Спс за топик — реально интересно было почитать.
1. Сервер Бизнес логики:
БД + реализация бизнесЛогики
Работа через обмен данными XML
2. Сервер ренедринга ( представления )
Обмен с [1] по XML, с клиентами — чем угодно, в случае с web — HTML / CSS / JS
Плюсы такой технологии:
1) возможности кластеризации серверов бизнес логики, либо разделения их по функционалу
2) возможность кластеризации серверов рендеринга, либо разделения их по функционалу
3) возможность кэширования документов [2]
4) возможность использования разных реализаций [1] и [2], но работающих как единое целое.
А в данном случае вы получаете очень тяжоловесную систему, во первых получить один БОЛЬШОЙ файл гораздо быстрее и легче, чем обработать 10 мелких запросов ( а я боюсь что во время интенсивной работы их у Вас будет куда больше ), вы откзываетесь от легковесных клиентов, где далеко не всегда можно использовать JS — не есть хорошо. Вы зависимы от скорости выполнения клиентских JS, т.к. инасе работа с системой превратится в нудную тягомотину.
Увы и ах — не понятны цели — ЗАЧЕМ? чтобы было так красиво все? Далеко не всегда красивое решение — это лучшее решение. К сожелению.
P.S. Спс за топик — реально интересно было почитать.
Если вы организуете бизнес логику на сервере, то как вы реализовали передачу сообщений на клиента для обработки отображения?
В чем отличие от обычного представления?
Например в RoR есть метод respond_to, который определяет как именно отдать данные, в зависимости от запроса, в тч «ни строчки HTML»
Смысл выделения новых сущностей для меня теряется…
Кроме того формирование запроса по средством ORM не это ли есть бизнес логика? Или вы хотите сказать, что контроллер теперь в браузере?
Например в RoR есть метод respond_to, который определяет как именно отдать данные, в зависимости от запроса, в тч «ни строчки HTML»
Смысл выделения новых сущностей для меня теряется…
Кроме того формирование запроса по средством ORM не это ли есть бизнес логика? Или вы хотите сказать, что контроллер теперь в браузере?
Круг замкнулся. Для решения задач, который ставит перед собой «совершенный аякс», лет тридцать назад применялись тонкие клиенты, написанные на компилируемых языках программирования. Да и Java Web Start фактически позволяет решать те же самые задачи.
Adobe AIR еще одно средство для выноса и разделения клиента и сервера в веб. Тут есть еще локальный сторейдж с файлами, которые коммуницируют с удаленными сервисами.
Убивают отдельные идеи отдавать аяксом сверстанный html в веб-приложении. К примеру клиент просит сервер удалить файл, какой html должен вернуть сервер? Такой:
<b>Да, я его удалил!</b>
А в случае неудачи такой:?
<b>этот гребаный файл не удаляется, потому что он занят другим приложением!</b>
А клиент, допустим, в зависимости от полученного ответа должен поступать по разному, и теперь чтобы понять был ли выполнен запрос ему надо распарсить этот html!
Или к примеру файловый менеджер, сервер отдает ему список файлов в виде таблицы со стоблцами «имя», «размер», «аттрибуты», и т.д. И теперь чтобы сделать нормальный кастомайзинг представления надо опять парсить html!
<b>Да, я его удалил!</b>
А в случае неудачи такой:?
<b>этот гребаный файл не удаляется, потому что он занят другим приложением!</b>
А клиент, допустим, в зависимости от полученного ответа должен поступать по разному, и теперь чтобы понять был ли выполнен запрос ему надо распарсить этот html!
Или к примеру файловый менеджер, сервер отдает ему список файлов в виде таблицы со стоблцами «имя», «размер», «аттрибуты», и т.д. И теперь чтобы сделать нормальный кастомайзинг представления надо опять парсить html!
Вы изобрели велосипед, причем на квадратных колесах.
Если вы хотите полноценной SOA — пожалуйста, свой сервер, свой протокол, спецификации и в итоге любые клиенты, втч. и c HTML
Но зачем эти гектолитры геморроя?
Если вы хотите полноценной SOA — пожалуйста, свой сервер, свой протокол, спецификации и в итоге любые клиенты, втч. и c HTML
Но зачем эти гектолитры геморроя?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Совершенный Ajax» – новый подход к построению настоящих клиент-серверных web-приложений