Архитектура взаимодействия клиентской и серверной частей Web приложения

[@retran]

Спасите нервные клетки тех кто после вас будет это поддерживать и почитайте про REST и WS-*. Пожалуйста.

[@dumistoklus]

Да, я согласен, и REST и WS нужно использовать. Но к сожалению, рест описывает не столько ответ сервера, сколько сам запрос. DELETE, GET, POST, PUT облегчат обращение к серверной части, но клиентскую надо еще будет писать.

Кстати, WebSocket работает в
Google Chrome (начиная с версии 4.0.249.0);
Apple Safari (начиная с версии 5.0.7533.16);
Mozilla Firefox (начиная с версии 4);
Opera (начиная с версии 10.70 9067);
и других менее используемых браузерах. Если нам нужны пользователи, которые сидят на «классических» браузерах, придется делать для них дублирующий функционал стандартными методами.

[@retran]

WS-* — это не вебсокеты. (с) Ваш кэп.

[@dumistoklus]

Вы имеете ввиду Web Services Transfer (WS-Transfer)
Web Services Eventing (WS-Eventing)
WS-Addressing Submission
и им подобные стандарты?

[@retran]

Именно.

[@AndrewStephanoff]

для таких пользователей fallback на flash / silverlight

[@dumistoklus]

Да, все что решает jQuery можно написать самостоятельно и не охватывает архитектуру. Но всё же это такой хороший помощник, позволяющий не кодить самые «нудные» места.
Если мы захотим избавится от jQuery — архитектура должна нам позволять заменить этот компонент, каким либо другим достаточно быстро.

Будет время подискутировать пишите в этот топик или в личку — буду очень рад. :)

[@nixmale]

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

Но вот «наши конкуренты», с таким же штатом что и у «нас», а это два человека, успевают сделать в месяц не два сайта, а четыре. Да, возможно им попались более легкие задачи чем нам, или просто производительность в этом месяце не на пределе, да множество причин могло повлиять, суть не в этом. Суть в том, что на создание интерфейсов у «нас» уходит больше времени, и если только не попадется заказчик, которому принципиально нужно без jQuery, то «мы» зря эту библиотеку не применяем. А могли бы чуть больше зарабатывать. Поэтому библиотека и популярна, что она помогает.

[@kuzemchik]

А еще прикольно, когда callback-и объявляют в виде функций, и вызывают их как функции в различных местах где «это нужно обновить тоже» =)

[@PQR]

К вопросоу о фреймвоках Application уровня. Оставлю здесь ссылочку на хороший обзор top 10 MVC JavaScript фреймворков: codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/

[@kuzemchik]

Про Backbone там кстати не очень точно:
Composed Views там есть так как объект Backbone.View и есть частичка представления. В частности представление Row может иметь свое представление генерируемуе в рамках render представления Table, и реализовывать полностью свою логику, он будет сам слушать свои события и обрабатывать свое представление изменяя DOM как ему нужно.
Ну а UI Bindings это скорее MVVM чем MVC.

[@spbcypher]

Как фанат Dojo могу посоветовать глянуть в сторону dojox.rpc.Service и deferred-объектов.
По поводу кеширования, в том же Dojo есть параметр preventCache, установка которого в true добавляет в запросы dummy-параметр со случайным значением.

[@vitalets]

Полезная статья, сам нечто подобное использую.
На счет обертки ajax в свою функцию — это палка о двух концах:
другой программист может не знать о существовании вашей обертки и написать кучу кода, указав все ручками.

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

[@dumistoklus]

другой программист может не знать о существовании вашей обертки и написать кучу кода, указав все ручками.

С другой стороны нагородив кучу кода, который поддерживает фрагмент, который нужен этому программисту, он не испортит, то что уже работает. Хотя программисты бывают разные =)

Не могли бы написать, какой вы видите структуру функции recognize?

К сожалению, нет. Не думаю, что я приведу достойный пример данной функции =)

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

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

[@kuzemchik]

Я в данный момент разбираю огромный интерфейс написанный на jQuery (с генерацией DOM в JS, ну и самый клевый элемент — json c сгенерированным html в значениях).
Все таки jQuery это инструмент манипуляции домом, но уж точно не инструмент построения интерфейса. Либо серверный темплейтер с примочками на js (но в этом случае никакой генерации DOM на клиенте), либо какой либо из упомянутых выше темплейтеров.

[@kuzemchik]

— нет
— вполне может быть, но после загрузки такого куска остальная перестройка интерфейса идет с помощью ajax и jquery)
— данные динамические (табовый интерфейс с кучей функциональноси)

Судя по истории тикетов, решение нифига не временное, так как такую махину написать (7 оы файлов в районе 14-ти фреймов). Но коллег сильно ругать нельзя, так что будем считать то решение было временное

P.S.
А вообще я писал не чтобы пожаловаться, а чтобы описать к чему примерно приводит проектирование больших интерфейсов на jQuery.

[@kuzemchik]

А мне, хоть я и люблю WPF и Silverlight с их MVVM, больше нравится backbone.js. По большей части, конечно, из-за underscore.js, но и сам backbone очень даже ничего. Сама концепция представления как отдельной сущности, а не темплейта — во мнгом упрощает жизнь. Очень понятным получается наследование представлений, что является слабым местом почти всех темплейтеров.

Сейчас пишу с require.js + backbone.js (очень похоже на backbone boilplate).

[@f0rk]

Backbone.Events же, в initialize вьюхи привязываем рендеринг к event-ам модели и все работает волшебно и прекрасно.

[@lair]

«Единая точка входа» — место для лучей ненависти всех, кто это будет потом поддерживать. Потому что разбирать эту «универсальную» мешанину всегда черезвычайно тяжело (именно благодаря ее универсальности).

[@FeNUMe]

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

[@lair]

Называется этот «модуль-роутер»… http-сервер.