Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Спасите нервные клетки тех кто после вас будет это поддерживать и почитайте про REST и WS-*. Пожалуйста.
Да, я согласен, и 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);
и других менее используемых браузерах. Если нам нужны пользователи, которые сидят на «классических» браузерах, придется делать для них дублирующий функционал стандартными методами.
Кстати, WebSocket работает в
Google Chrome (начиная с версии 4.0.249.0);
Apple Safari (начиная с версии 5.0.7533.16);
Mozilla Firefox (начиная с версии 4);
Opera (начиная с версии 10.70 9067);
и других менее используемых браузерах. Если нам нужны пользователи, которые сидят на «классических» браузерах, придется делать для них дублирующий функционал стандартными методами.
WS-* — это не вебсокеты. (с) Ваш кэп.
Вы имеете ввиду Web Services Transfer (WS-Transfer)
Web Services Eventing (WS-Eventing)
WS-Addressing Submission
и им подобные стандарты?
Web Services Eventing (WS-Eventing)
WS-Addressing Submission
и им подобные стандарты?
для таких пользователей fallback на flash / silverlight
Да, все что решает jQuery можно написать самостоятельно и не охватывает архитектуру. Но всё же это такой хороший помощник, позволяющий не кодить самые «нудные» места.
Если мы захотим избавится от jQuery — архитектура должна нам позволять заменить этот компонент, каким либо другим достаточно быстро.
Будет время подискутировать пишите в этот топик или в личку — буду очень рад. :)
Если мы захотим избавится от jQuery — архитектура должна нам позволять заменить этот компонент, каким либо другим достаточно быстро.
Будет время подискутировать пишите в этот топик или в личку — буду очень рад. :)
Никогда не пользовался jQuery и был доволен тем, что собственные решения всегда компактнее, так как пишутся под задачу и более ничего лишнего.
Но вот «наши конкуренты», с таким же штатом что и у «нас», а это два человека, успевают сделать в месяц не два сайта, а четыре. Да, возможно им попались более легкие задачи чем нам, или просто производительность в этом месяце не на пределе, да множество причин могло повлиять, суть не в этом. Суть в том, что на создание интерфейсов у «нас» уходит больше времени, и если только не попадется заказчик, которому принципиально нужно без jQuery, то «мы» зря эту библиотеку не применяем. А могли бы чуть больше зарабатывать. Поэтому библиотека и популярна, что она помогает.
Но вот «наши конкуренты», с таким же штатом что и у «нас», а это два человека, успевают сделать в месяц не два сайта, а четыре. Да, возможно им попались более легкие задачи чем нам, или просто производительность в этом месяце не на пределе, да множество причин могло повлиять, суть не в этом. Суть в том, что на создание интерфейсов у «нас» уходит больше времени, и если только не попадется заказчик, которому принципиально нужно без jQuery, то «мы» зря эту библиотеку не применяем. А могли бы чуть больше зарабатывать. Поэтому библиотека и популярна, что она помогает.
К вопросоу о фреймвоках Application уровня. Оставлю здесь ссылочку на хороший обзор top 10 MVC JavaScript фреймворков: codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
Про Backbone там кстати не очень точно:
Composed Views там есть так как объект Backbone.View и есть частичка представления. В частности представление Row может иметь свое представление генерируемуе в рамках render представления Table, и реализовывать полностью свою логику, он будет сам слушать свои события и обрабатывать свое представление изменяя DOM как ему нужно.
Ну а UI Bindings это скорее MVVM чем MVC.
Composed Views там есть так как объект Backbone.View и есть частичка представления. В частности представление Row может иметь свое представление генерируемуе в рамках render представления Table, и реализовывать полностью свою логику, он будет сам слушать свои события и обрабатывать свое представление изменяя DOM как ему нужно.
Ну а UI Bindings это скорее MVVM чем MVC.
Как фанат Dojo могу посоветовать глянуть в сторону dojox.rpc.Service и deferred-объектов.
По поводу кеширования, в том же Dojo есть параметр preventCache, установка которого в true добавляет в запросы dummy-параметр со случайным значением.
По поводу кеширования, в том же Dojo есть параметр preventCache, установка которого в true добавляет в запросы dummy-параметр со случайным значением.
Полезная статья, сам нечто подобное использую.
На счет обертки ajax в свою функцию — это палка о двух концах:
другой программист может не знать о существовании вашей обертки и написать кучу кода, указав все ручками.
Не могли бы написать, какой вы видите структуру функции recognize?
Например, я бы выделил такие общие задачи как показать всплывающее сообщение или редиректнуть пользователя на определенный урл.
На счет обертки ajax в свою функцию — это палка о двух концах:
другой программист может не знать о существовании вашей обертки и написать кучу кода, указав все ручками.
Не могли бы написать, какой вы видите структуру функции recognize?
Например, я бы выделил такие общие задачи как показать всплывающее сообщение или редиректнуть пользователя на определенный урл.
другой программист может не знать о существовании вашей обертки и написать кучу кода, указав все ручками.
С другой стороны нагородив кучу кода, который поддерживает фрагмент, который нужен этому программисту, он не испортит, то что уже работает. Хотя программисты бывают разные =)
Не могли бы написать, какой вы видите структуру функции recognize?
К сожалению, нет. Не думаю, что я приведу достойный пример данной функции =)
Например, я бы выделил такие общие задачи как показать всплывающее сообщение или редиректнуть пользователя на определенный урл.
Да Вы правы, общие задачи я бы тоже выделил в отдельные функции. Только еще бы разделил всплывающие сообщения на ошибки и уведомления.
И еще добавил в стандартный функционал бы доставку серверного лога для dev версии проекта для разработчиков.
Я в данный момент разбираю огромный интерфейс написанный на jQuery (с генерацией DOM в JS, ну и самый клевый элемент — json c сгенерированным html в значениях).
Все таки jQuery это инструмент манипуляции домом, но уж точно не инструмент построения интерфейса. Либо серверный темплейтер с примочками на js (но в этом случае никакой генерации DOM на клиенте), либо какой либо из упомянутых выше темплейтеров.
Все таки jQuery это инструмент манипуляции домом, но уж точно не инструмент построения интерфейса. Либо серверный темплейтер с примочками на js (но в этом случае никакой генерации DOM на клиенте), либо какой либо из упомянутых выше темплейтеров.
— нет
— вполне может быть, но после загрузки такого куска остальная перестройка интерфейса идет с помощью ajax и jquery)
— данные динамические (табовый интерфейс с кучей функциональноси)
Судя по истории тикетов, решение нифига не временное, так как такую махину написать (7 оы файлов в районе 14-ти фреймов). Но коллег сильно ругать нельзя, так что будем считать то решение было временное
P.S.
А вообще я писал не чтобы пожаловаться, а чтобы описать к чему примерно приводит проектирование больших интерфейсов на jQuery.
— вполне может быть, но после загрузки такого куска остальная перестройка интерфейса идет с помощью ajax и jquery)
— данные динамические (табовый интерфейс с кучей функциональноси)
Судя по истории тикетов, решение нифига не временное, так как такую махину написать (7 оы файлов в районе 14-ти фреймов). Но коллег сильно ругать нельзя, так что будем считать то решение было временное
P.S.
А вообще я писал не чтобы пожаловаться, а чтобы описать к чему примерно приводит проектирование больших интерфейсов на jQuery.
А мне, хоть я и люблю WPF и Silverlight с их MVVM, больше нравится backbone.js. По большей части, конечно, из-за underscore.js, но и сам backbone очень даже ничего. Сама концепция представления как отдельной сущности, а не темплейта — во мнгом упрощает жизнь. Очень понятным получается наследование представлений, что является слабым местом почти всех темплейтеров.
Сейчас пишу с require.js + backbone.js (очень похоже на backbone boilplate).
Сейчас пишу с require.js + backbone.js (очень похоже на backbone boilplate).
«Единая точка входа» — место для лучей ненависти всех, кто это будет потом поддерживать. Потому что разбирать эту «универсальную» мешанину всегда черезвычайно тяжело (именно благодаря ее универсальности).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура взаимодействия клиентской и серверной частей Web приложения