Comments 23
UFO just landed and posted this here
Я сам пишу ныне все AJAX-базированные приложения исключительно на JSON. Скажем, JS код билиотеки управления деревом структуры с Drag&Drop и контекстным меню сократился почти в 2 раза, скорость работы приложения выросла раза в три, код легче понять (а это важно, так как для open source проекта пишется) и т.д. Однако в нас компании практикуется и XML для унификации контроллера, возможности разибрать его ответ в сторонних приложениях
0
UFO just landed and posted this here
AJAX хорошо использовать по смыслу а не везде подряд! как нынче модно! браузеры пока еще не поддерживают (в план организации интерфейса) его...
Допустим хочешь показать другу то, что увидел... а ссылка то не сменилась с момента захода на сайт!
Мое мнение, AJAX хорошо в меру...
Ждем поддержку браузерами аякса...
Допустим хочешь показать другу то, что увидел... а ссылка то не сменилась с момента захода на сайт!
Мое мнение, AJAX хорошо в меру...
Ждем поддержку браузерами аякса...
-1
А при чем тут браузеры? Это, скорее, дело приложения. Да, конечно было бы здорово, если бы javascript-код мог бы менять урл в адресной строке без фактического перехода. Но и сейчас есть варианты обхода этой проблемы - делаем урлы с якорями, и повсюду пихаем ссылки permalink. В общем, жить можно ;)
0
Пишите на флеше :) все таки AS3 это ООП в отличие от JS.
Нет головных болей от платформы/браузера...флеш либо установлен - либо его нет.
Нет головных болей от платформы/браузера...флеш либо установлен - либо его нет.
0
В общем случае:
- Флеш в разработке дороже (даже если брать среднюю цену на рынке)
- Флеш сам по себе тяжелее (я имею ввиду размер swf)
> флеш либо установлен - либо его нет.
Браузер установлен в подавляющем большинстве случаев.
> Нет головных болей от платформы/браузера...
Согласен... Это огромный плюс.
- Флеш в разработке дороже (даже если брать среднюю цену на рынке)
- Флеш сам по себе тяжелее (я имею ввиду размер swf)
> флеш либо установлен - либо его нет.
Браузер установлен в подавляющем большинстве случаев.
> Нет головных болей от платформы/браузера...
Согласен... Это огромный плюс.
0
> флеш либо установлен - либо его нет.
Может в это сложно поверить, но я наелся досыта проблемами, возникающими с флешом в разных браузерах. Например, в ФФ 1.5 флешка высотой больше одного экрана не может корректно реагировать на мышь в промежуточных положениях скроллинга. В некоторых операх у флешки съезжает отображение текста и т.п. Так что не так все просто!
Может в это сложно поверить, но я наелся досыта проблемами, возникающими с флешом в разных браузерах. Например, в ФФ 1.5 флешка высотой больше одного экрана не может корректно реагировать на мышь в промежуточных положениях скроллинга. В некоторых операх у флешки съезжает отображение текста и т.п. Так что не так все просто!
0
а кто сказал, что js это не ООП?
0
>>а ссылка то не сменилась с момента захода на сайт!
а для этого можно делать специальные штуки типа "ссылка на эту страницу"
а для этого можно делать специальные штуки типа "ссылка на эту страницу"
0
а как сокращается размер передаваемой информации :)
0
и, наоборот, сервер может передать данные браузеру в любой момент, а не только лишь тогда, когда запрашивается новая страница
ну это вы, конечно, загнули! это каким же макаром сервер сам отправляет данные в браузер?
0
Пока этого нет, но рождается :)
http://cometd.com/
http://cometd.com/
+1
По запросу браузера, асинхронно. :)
Поставил реакцию на приход данных и пусть пользователь делает что ему надо.
Поставил реакцию на приход данных и пусть пользователь делает что ему надо.
0
Имеется ввиду - когда нет явного запроса (Reverse AJAX). Конечно на стороне клиентского приложения регулярно совершаются обращения к серверу, но пользователь в этом не принимает участия. Для него это выглядит, так как если бы сервер вдруг постучался в браузер и заявил что лимит места на сервере закончился или что-либо еще.
0
Есть разные техники - как те, что тут упомянули (периодический опрос сервера), так и более "синхронные".
Например, ajax-приложение может делать запрос к серверу, а сервер - не отвечать сразу, а держать это соединение открытым, пока для этого клиента не появятся данные. Как только появилась информация для передачи клиенту - сервер отдает ответ и закрывает соединение. А клиент, получив информацию, тут же открывает новое соединение для ожидания новой порции данных (кстати, так работает внутренняя переписка на damochka.ru - но там не js, а java).
Как вариант - можно не закрывать соединение, а просто "подпихивать" очередные порции данных - но в этом случае усложняется реализация и возникает много дополнительных проблем.
Например, ajax-приложение может делать запрос к серверу, а сервер - не отвечать сразу, а держать это соединение открытым, пока для этого клиента не появятся данные. Как только появилась информация для передачи клиенту - сервер отдает ответ и закрывает соединение. А клиент, получив информацию, тут же открывает новое соединение для ожидания новой порции данных (кстати, так работает внутренняя переписка на damochka.ru - но там не js, а java).
Как вариант - можно не закрывать соединение, а просто "подпихивать" очередные порции данных - но в этом случае усложняется реализация и возникает много дополнительных проблем.
0
А теперь представьте ресурс с большой посещаемостью, который будет должен держать сразу сотни "постоянных" соединений.
0
Ничего страшного. Обычный сервер Apache поддерживает 256 постоянных соединений, но простым жестом руки, изменяющим эту константу, можно добиться любого количества открытых соединений. Это часто используется в чатах, где 300-400 одновременных KeepAlive соединений вполне обычное дело. Но есть более эффективные техники, позволяющие получать тот же эффект с меньшими затратами.
0
Делать чат на апаче крайне накладно - поскольку апач каждое соединение обрабатывает в отдельном процессе (1.3 так делает всегда, да и 2.x обычно настраивают именно так). Для операционной системы эти сотни-тысячи процессов - очень большая нагрузка.
Поэтому для постоянных соединений единственный вариант - мультиплексирование, когда один процесс по очереди обрабатывает много соединений. Так работают web-серверы nginx, lighttpd и другие.
Поэтому для постоянных соединений единственный вариант - мультиплексирование, когда один процесс по очереди обрабатывает много соединений. Так работают web-серверы nginx, lighttpd и другие.
0
И в чем проблема? ;) Держат, еще как! На самом деле, держать кучу таких открытых соединений не трудно, если аккуратно с ними работать. Конечно, это должен быть не apache+cgi или apache+mod_php, а, чаще всего, какой-то отдельный демон, написанный на компилируемом языке.
Кстати, приходите на конференцию, в первый день Игорь Сысоев расскажет, как настроить FreeBSD для работы с 100-200 тысячами соединений.
Кстати, приходите на конференцию, в первый день Игорь Сысоев расскажет, как настроить FreeBSD для работы с 100-200 тысячами соединений.
0
РГЛаб начал PR-активности на Хабре... :)
Подскажите кто из вас под ником этим сидит?
Подскажите кто из вас под ником этим сидит?
0
Sign up to leave a comment.
Rich Internet Application и управление контентом