Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 145
полезно, спасибо!
на хабре тенденция минусовать первый коммент??
на хабре традиция первый коммент ("полезно, спасибо!") плюсовать до 24-36, потом через 20 комментариев кто-то говорит "гавно" и еще десяток комментов ниже о том же плюсуют до 5-10. Синусойдо опасносте.
лоджико опасносте
ажякс опасносте
и теперь моя карма тоже... пыщьпыщь кал'айдер в действии!!!""22двадва
ажякс опасносте
и теперь моя карма тоже... пыщьпыщь кал'айдер в действии!!!""22двадва
вот это суровая правда жизни.
имеется у нас как-то проект один который полностью построен на аяксе, т.е. минимум переходов по страницам (так захотел заказчик). в итоге этот портал просто монстрообразен, код ужасен, куча скриптов совершенно не нужных (если мыслить логически про переходы), и попытка отрыть оный в ИЕ6 его просто вешает.
имеется у нас как-то проект один который полностью построен на аяксе, т.е. минимум переходов по страницам (так захотел заказчик). в итоге этот портал просто монстрообразен, код ужасен, куча скриптов совершенно не нужных (если мыслить логически про переходы), и попытка отрыть оный в ИЕ6 его просто вешает.
>делает работу сайта непредсксказуемой и ощутимо затормаживает работу даже на новейших компьютерах
руки. прямые руки, которые не тянутся к фреймворкам и действуют не сами по себе, а центролизовано (от головы)
руки. прямые руки, которые не тянутся к фреймворкам и действуют не сами по себе, а центролизовано (от головы)
HTTP RefeRRer
Вы перепутали с выражением Referral Url
Объект Referer, а свойство document.referrer
Каюсь, перепутал, но зачем минусы-то ставить?(
"К примеру для несложных манипуляций замечательно подойдёт YAML или CSV, а XML будет излишне толстым"
А как же JSON?
А как же JSON?
JSON, не смотря на все свои прелести - пока мало используем...
Да и чаще всего грузится все таки обычный HTML ... Вот поэтому наверное и забыли указать ....
Да и чаще всего грузится все таки обычный HTML ... Вот поэтому наверное и забыли указать ....
Статистику покажите. Почему вы думаете, что его используют мало?
JSON мало используем? Ой, кажется, я не в том мире живу.
Я не говорю за всех .. и минусовать - это плохой тон для диалога...
Больше говорить ничего не хочется.. спсб
Больше говорить ничего не хочется.. спсб
я тебя не минусовал — в карме твоей вообще плюс стоит
да, и как же вы надоели со своими "ой минусуют", честное слово. ладно, бог с тобой
да, и как же вы надоели со своими "ой минусуют", честное слово. ладно, бог с тобой
Да просто неприятно очень когда без дела... а чисто от плохого настроения...
Не суть..
Вообщем я про что ... У нас контора разработывает системы Telebank и прочие для проведения финансовых операций через internet... так вот JSON Используется только в одном приложении из многих... Потому что в остальных AJAX отвечает только за доставку контента (функционального в том числе)...
И, я предположу, что в системах где главной задачей AJAX является всего лишь доставка контента чаще всего работают с бональным HTML c примесью скриптов внутри...
Но это всего лишь предположение....
Не суть..
Вообщем я про что ... У нас контора разработывает системы Telebank и прочие для проведения финансовых операций через internet... так вот JSON Используется только в одном приложении из многих... Потому что в остальных AJAX отвечает только за доставку контента (функционального в том числе)...
И, я предположу, что в системах где главной задачей AJAX является всего лишь доставка контента чаще всего работают с бональным HTML c примесью скриптов внутри...
Но это всего лишь предположение....
достаточно странно перекидывать большие хтмл-штуки через аякс. я бы (может, я и не прав), придумал бы как формировать из полученных данных хтмл уже на клиенте, загрузив один раз скрипт для формирования
Отработка скрипта по обработке контента на клиенте - особенно на медленной машине может стать проблемой...
Решено было делать просто и быстро...
Решено было делать просто и быстро...
далеко не всегда. я же не предлагаю на клиенте bbcode перелопачивать, я про то, что если нужно список вывести — дешевле, в т.ч. для обработки, послать массивом. тем более, innerHTML и прочее не рекомендуется
ps: а зачем... эти... троеточия...? :)
ps: а зачем... эти... троеточия...? :)
Это я думаю так - троеточиями )
Странно, я думаю головой, а не троеточиями.
Многоточие, блин... мно-го-то-чи-е!
Да я-то знаю, что многоточие, но 
randoom
randoom
и кроме того, на стороне клиента можно скины организовать или прочие прелести обработки чистых данных :) Потому JSON, XML, etc предпочтительнее. Хотя, опять же, бывает проще обухом...
а я вот не соглашусь, пожалуй. На сколько помню, innerHTML таки в W3C имеется, более того, он более чем в 3 раза быстрее, чем тот же DOM (смотрим тесты JS DOM vs innerHTML на хабре), этого достаточно, чтобы хотя б рассмотреть возможность его применения для статики.
списочек - возможно и проще. но чаще вывод более сложный. плюс ко всему - я предпочту поменять шаблон вывода на сервере (особенно если не просто внешний вид сменился, а, например, колонка новая добавилась с данными).
А есть какие-нибудь данные на эту тему?
Я выбрал именно ваш путь решения этой проблемы. В этом случае JSON просто незаменим. Если грамотно составить документ, то, в отличии от XML, его даже не надо разбирать, что бы на основе полученных данных строить HTML. В общем все круто, но меня несколько пугает мысль о том, что прийдется строить достаточно большие документы (сейчас строятся таблицы 10-20 строк).
Я выбрал именно ваш путь решения этой проблемы. В этом случае JSON просто незаменим. Если грамотно составить документ, то, в отличии от XML, его даже не надо разбирать, что бы на основе полученных данных строить HTML. В общем все круто, но меня несколько пугает мысль о том, что прийдется строить достаточно большие документы (сейчас строятся таблицы 10-20 строк).
а что такого страшного-то? :)
жсон по сети передастся быстрее, и распарсится и обработается вряд ли медленнее, чем хмл
жсон по сети передастся быстрее, и распарсится и обработается вряд ли медленнее, чем хмл
Я имел ввиду насколько затратно собирать HTML на клиенте.
Думаю попозже напишу скриптик и посмотрю как сильно построение страничек грузит браузер.
Думаю попозже напишу скриптик и посмотрю как сильно построение страничек грузит браузер.
давайте, а результаты бенчмарка покажете :)
и сравните с хмл и прочим ;)
и сравните с хмл и прочим ;)
Нене... Я всеми руками за JSON. Я уже писал, что меня в нем привлекает сравнительно малый объем передаваемых данных и возможность исключения предварительно обработки перед использованием.
Мне интересно не убъет ли построение больших страниц браузер. Может в некоторых случаях лучше строить шаблонизатором HTML и просто вставлять его на страницу?
Мне интересно не убъет ли построение больших страниц браузер. Может в некоторых случаях лучше строить шаблонизатором HTML и просто вставлять его на страницу?
вы gmail видели? :) не убивает же
Loengreen эх, были же времена :)
Вы попробуйте на примере больших данных :) Будет интересно
а наша контора перекидывает через аякс готовые штмльные куски только в уникальных случаях.
Json уже года два как нашел прибежище во всех наших либах для аяксовой передачи данных.
Json уже года два как нашел прибежище во всех наших либах для аяксовой передачи данных.
json'a меньше чем ямла или цвс?
JSON используется для решения cross domain browser security. Это когда надо послать запрос на скрипт, находящийся на другом домене. Например, при колбеках.
JSON есть частью YAML
JSON проще всего, использую только его: на php json_encode(), json_decode(), вот только на JS json_encode пришлось реализовать ручками.
Спасибо, правда спасибо... Все знал - но читать было приятно....
Отплюсовал, как говорится )
Отплюсовал, как говорится )
Интересно было бы почитать про то, есть ли какие-то доступные способы оптимизации страниц с большим количеством аякса для поисковых ботов.
я делал пару сайтов фактически как AJAX приложения и там была задача обеспечения индексации. Надо сказать, что по JS ссылкам не все боты ходить умеют, поэтому делать пришлось немного через заднее место. Был добавлен скрытый фрейм, в котором все ссылки сайта меняли информацию, он ребутился каждый раз и выводил тексты сам в себя, на нем же были скрипты, которые меняли нужные parent.* блоки, чтобы не загружать контент по второму разу, таким образом компромис получился неплохим. Боты в основном индексировали содержимое фрейма, а люди видели копирование контента из этого фрейма в основной шаблон, так как фрейм скрытый, на его рендеринг время на клиенте не тратилось.
я делал так - страница загружается с обычными ссылками, но те ссылки, которые, в случае наличии у клиента работающего яваскрипта, должны грузится c использованием AJAX, имеют rel="ajax" и onload="функция загрузки аяксом". При наступлении события Domready запускается javascript (если он есть) и заменяет ссылки на "javascript:void(0)". По-этому сайт работает как без яваскрипта (читай AJAXа), так и с ним. Проблем с индексацией нет. Правда такой подход не решает проблему кнопки "Назад".
>Так же проверяйте HTTP Referer - ибо это важно
сталкнулся один раз, что у клиента в офисе был как то настроен фаервол, что их браузеры не отправляли HTTP Referer, пришлось Referer руками прописывать у каждой формы в хидден
сталкнулся один раз, что у клиента в офисе был как то настроен фаервол, что их браузеры не отправляли HTTP Referer, пришлось Referer руками прописывать у каждой формы в хидден
AJAX появился благодаря Microsoft, не стоит принижать их роль. Именно они придумали XMLHTTP с которого всё началось.
Так же, рассказывая про AJAX, нельзя не упомянуть JSON, это более к месту, чем YAML.
Так же, рассказывая про AJAX, нельзя не упомянуть JSON, это более к месту, чем YAML.
AJAX появился благодаря толстым каналам. То, что XMLHttpRequest удобен - это правда, но что незаменим - нет. Можно делать динамические сайты с помощью фреймов. Мы такие вещи делали во времена когда поддержка Netscape 4.x была актуальна, а термина AJAX ещё не было. С полноценной модификацией сайтов "на лету" при получении новой информации от сервера и прочим. Не так удобно, да, но и не смертельно сложно.
можно засунуть обе реазилации, через фреймы и XMLHttpRequest в один объект, сделать общий интерфейс и не париться :)
Я тоже делал это фреймами, мой знаменитый чат (стоял, например, у Экслера на сайте) был сделан именно так.
Объясните связь AJAX и толстых каналов. AJAX как раз помогает экономить трафик.
Объясните связь AJAX и толстых каналов. AJAX как раз помогает экономить трафик.
Очень интересно было почитать. Спасибо!
Понравилось то что "браузеры от Microsoft" как-то не так работают с Ajax, учитывая то что в Microsoft его и придумали.
Вообще для начинающего веб-разработчика оч хорошая статья. + вам ;)
Вообще для начинающего веб-разработчика оч хорошая статья. + вам ;)
Microsoft не придумал AJAX. Microsoft придумал XMLHttpRequest - это сильно не одно и то же.
Тоже верно. Но 1) в статье наверняка и имелся ввиду сам объект (хотя написано Ajax) 2) не будь XMLHttpRequest не было бы и Ajax'а (хотя кто его знает) 3) Microsoft придумала не XMLHttpRequest, а ActiveXObject(Microsoft.XMLHTTP).
В любом случае спасибо за поправку.
В любом случае спасибо за поправку.
не будь XMLHttpRequest - был бы аякс через фреймы :)
Отчасти так - первыми реализацию такого метода сделали в Microsoft, но действительно использовать его стали только через несколько лет. Я думаю, это следствие развития стандартов, в частности, того же DOM. Так что если бы к моменту созревания потребности в AJAX не было XMLHttpRequest, его бы всё равно сделали. :)
Конечно, его стали использовать сразу, а не через несколько лет, это получил распространение он через несколько лет, так как 99% веб-программистов не интересуются возможностями браузеров. Лично я использовал XMLHttpRequest и VML очень давно — ещё когда занимался интранетами (там было возможно сказать «используйте только этот браузер»).
По-моему он сильно получил распостранение после того, как крупные игроки начали его использовать, а все остальные просто пошли за ними. GMail был, вроде, первым веб-приложением сильно использующим AJAX. нет?
Прости, господи, неужели он блюет в ноутбук?
Не соглашусь что обязательно нужно знать Javascript для использования AJAX. Можно вполне заменить его тем же PHP, есть библиотеки типа Projax которые переводят PHP код в JS.
GWT и прочее безобразие....
Они к сожалению дают перегруженные приложения... которые бонально медленно работают - ибо содержат много лишнего..
Для разработки AJAX приложения в промышленных масштабах обязательно знание JavaScript
Они к сожалению дают перегруженные приложения... которые бонально медленно работают - ибо содержат много лишнего..
Для разработки AJAX приложения в промышленных масштабах обязательно знание JavaScript
Не думаю что простейшее преобразование которое выполняет библиотека ($projax->remove('box') => Element.remove('box')) как-то влияет на скорость. Да и потом, никто не мешает посмотреть потом исходный код страницы и скопировать получившийся JS код - таким образом и Javascript как раз можно выучить :) Я именно так сейчас и делаю.
Неправильно вы делаете, откройте, хотябы, сайт JavaScript Tutorial и прочитайте. Самого языка javascript - раз два и обчелся + DOM немного подтяните, так вы будете знать все изнутри. Откуда вы, например, уверены, что ваш кодогенератор генерирует скрипт самым оптимальным образом?
Вот именно про неоптимальность кода от таких вещей я и говорил....
Я просто говорю о том, что это лучший вариант для человека, коотрый знает PHP, но не знает JS. Лучше использовать такие вот "мосты" и иметь работающий и возможно немного кривой AJAX (хотя я в кривости очень сомневаюсь - prototype js framework настолько четкий и понятный что трудно что-то там сделать криво), чем не иметь его вообще. Не у всех есть время вникать.. Оптимальностью кода можно заняться и потом, первоочередная задача - рабочий проект!
Первоочередная задача в любом проекте - это
1) Корректное проектирование плана работ по проекту с оценкой трудоемкости
2) Привлечение всех необходимых специалистов (Клиентской стороной не должен заниматься PHP-шник)
3) И только потом реализация проекта...
Но, я говорю про коммерческий проект... а если на уровне "Поиграться" - то можно и поиграться... )))
Опять же Google - тоже был забавой )
1) Корректное проектирование плана работ по проекту с оценкой трудоемкости
2) Привлечение всех необходимых специалистов (Клиентской стороной не должен заниматься PHP-шник)
3) И только потом реализация проекта...
Но, я говорю про коммерческий проект... а если на уровне "Поиграться" - то можно и поиграться... )))
Опять же Google - тоже был забавой )
если проектом занимается один человек - все намного проще :)
Клиентской стороной не должен заниматься пхпшник.
В корне согласен. Серверный скрипт, что выдает страничку на выходе изначально имеет иную ориентацию, иной подход, нежели Javascript, выполняющийся на клиентской стороне - у последнего проблема утечки памяти стоит гораздо актуальней, плюс взаимодействие и порядок выполнения асинхронных запросов. Для непривычного человека это может обернуться адом.
В корне согласен. Серверный скрипт, что выдает страничку на выходе изначально имеет иную ориентацию, иной подход, нежели Javascript, выполняющийся на клиентской стороне - у последнего проблема утечки памяти стоит гораздо актуальней, плюс взаимодействие и порядок выполнения асинхронных запросов. Для непривычного человека это может обернуться адом.
Я отвечал на конкретно эту вашу фразу:
таким образом и Javascript как раз можно выучить :) Я именно так сейчас и делаю.
а во что тут вникать? в синтаксис? Вы же не сможете теже event'ы сначала на php писать, а топом в js конвертить, а если сможете, то точно один синтаксис :)
Вы уже второй раз пишете, не смог удержаться.
Правильно писать бАнально, если вам уж так нравится это слово :)
Правильно писать бАнально, если вам уж так нравится это слово :)
Сайты можно и в Ворде делать, правда же?
Потому, если вы хотите написать грамотное во всех отношения Ajax-приложение, вам придётся писать на JS - по другому никак.
Потому, если вы хотите написать грамотное во всех отношения Ajax-приложение, вам придётся писать на JS - по другому никак.
Другим кроссбраузерным вариантом был когда-то IFRAME-лоадер.Ммм... странная кроссбраузерность - не так много есть браузеров с поддержкой IFRAME и без XMLHttpRequest. Разве что Opera старых версий - но она никогда особенно актуальна не была. А для Netscape 4.x (когда это было актуально) нужно использовать полноценные FRAME...
И все таки - это унитаз - или просто у меня что то с фантазией? ;)
Самому интересно. Наверное, зависит от разработчика.
Владельцы ФФ, в предыдущем сообщении вы видете альт от кртинки, криво вставленной с «народа», сорри. Вот прямой линк: http://homm86.narod.ru/files/ajax.jpg
Я бы еще 1 совет добавил: Не изобретайте велосипедов. Используйте библиотеки (jQuery, Prototype и др). Они кроссбраузерны, гибкие и удобные
Совет номер два... Не используйте визуалку из библиотек(ExtJS, Backbase и проч.). Делайте свою - а ядро лучше не изобретать.
Почему?
Потому что они все из себя красявые - но когда вам заказчик скажет - а хочу "красненькую" а визуальный компонент не сможет - придется переписывать половину кода.....
Так они же легко скинуются CSS-ом (по крайней мере, в YUI - ExtJS ещё не смотрел).
Под "красненькой" я имел не только цвет.. а какие нить принципиальные заскоки которые ye просто умереть-не-встать нужны клиенту...
Складывается мнение, что Вы не достаточно хорошо знакомы, допустим, с тем же ExtJS.
В нем созданы БАЗОВЫЕ "классы" интерфейсов. Надо "красненькое" - расширяй, улучшая и дописывай. API открыт. Впрочем, это касается каждого из фреймворков.
Мне дорого мое время, как и большиству здравомыслящих разработчиков.
В нем созданы БАЗОВЫЕ "классы" интерфейсов. Надо "красненькое" - расширяй, улучшая и дописывай. API открыт. Впрочем, это касается каждого из фреймворков.
Мне дорого мое время, как и большиству здравомыслящих разработчиков.
Никогда не понимал смысла библиотек. Какая разница что учить - библиотеки или сам язык?
а что в аяксе такого не кроссбраузерного? создание объекта, да баг ие6 с for in для аттрибутов. про гибкость библиотек в плане аякса спорить не буду, но скажу, что в этом плане у них имеется только наработанный материал.
Статья неактуальна. AJAX уже миллион раз обсудили и давно используют.
Советы малоактуальны, т.к. большинство (я так думаю) использует готовые классы или фреймворки, где всё уже итак оптимизировано по максимуму.
Кроме того, я считаю, что использование XML в AJAX-транзакциях в 95% случаях нерационально. По двум причинам:
1) XML сложнее и дольше парсить, чем JSON или YAML. Соответственно, возникает неоправданная нагрузка и на серверный, и на клиентский скрипт.
2) XML больше по объему, что опять же неоправданно.
Стоит XML использовать в реально больших приложениях со сложной логикой работы, что и составляет 5%.
Сам я использую JSON, ибо благодаря Json.Remote в mootools код занимает пару строк =)
Советы малоактуальны, т.к. большинство (я так думаю) использует готовые классы или фреймворки, где всё уже итак оптимизировано по максимуму.
Кроме того, я считаю, что использование XML в AJAX-транзакциях в 95% случаях нерационально. По двум причинам:
1) XML сложнее и дольше парсить, чем JSON или YAML. Соответственно, возникает неоправданная нагрузка и на серверный, и на клиентский скрипт.
2) XML больше по объему, что опять же неоправданно.
Стоит XML использовать в реально больших приложениях со сложной логикой работы, что и составляет 5%.
Сам я использую JSON, ибо благодаря Json.Remote в mootools код занимает пару строк =)
недавно надо было переписать с флеша на аджакс довольно сложное приложение - (livesupport чат)
мне как php девелоперу джаваскрипт всегда был противен и в 90% случаев вызывал лишь рвотные рефлекс. по'тому перспектива разработки довольно крупного приложения на языке который я не знаю меня естественно совсем не радовала. Но все оказалось намного проще - я посвятил несколько дней на пролистывания джаваскрипт библии, потом взял jQuery, сделал несколько тестовых приложений.. И сегодня могу с уверенностью сказать - аджакс в 90% случаев это легко и просто. на сегодняшний день не нужно изобретать колеса, благодаря доступным фреймворкам работа с аджаксом приносит огромное удоольствие!
(но на обьектную модель в джаваскрипте все так же, хочется блевать)
мне как php девелоперу джаваскрипт всегда был противен и в 90% случаев вызывал лишь рвотные рефлекс. по'тому перспектива разработки довольно крупного приложения на языке который я не знаю меня естественно совсем не радовала. Но все оказалось намного проще - я посвятил несколько дней на пролистывания джаваскрипт библии, потом взял jQuery, сделал несколько тестовых приложений.. И сегодня могу с уверенностью сказать - аджакс в 90% случаев это легко и просто. на сегодняшний день не нужно изобретать колеса, благодаря доступным фреймворкам работа с аджаксом приносит огромное удоольствие!
(но на обьектную модель в джаваскрипте все так же, хочется блевать)
а я не запаривался с библиотеками, я сидел в чистом жаваскрипте... и о чудо! рвотные рефлексы прошли :)
А чем не нравится объектная модель?
Он по привычке пытается искать классы и интерфейсы среди объектов и прототипов :)
да впринципе примитивизм и не понравился. отсутствие статических переменных тоже не понравилось, область видимости тоже первое время не нравилась
JavaScript — чудесный язык! Нужно только «уметь его готовить» )
Сначала сам плевался и считал, что ни на что, кроме простецких скриптов он не способен, потом почитал 38, 39 и 40 статьи куроводства и, спустя пару-тройку скриптов, изменил свое мнение. Это очень своеобразный язык, но вполне симпатичный и удобный в своей своеобразности (ИМХО, конечно. И простите за каламбур).
Фреймворки — это хорошо. Когда понимаешь, что происходит внутри фреймворка и как можно выполнить задачу без него — еще лучше. Для некоторых задач использование фреймворков просто не оправдано.
Сначала сам плевался и считал, что ни на что, кроме простецких скриптов он не способен, потом почитал 38, 39 и 40 статьи куроводства и, спустя пару-тройку скриптов, изменил свое мнение. Это очень своеобразный язык, но вполне симпатичный и удобный в своей своеобразности (ИМХО, конечно. И простите за каламбур).
Фреймворки — это хорошо. Когда понимаешь, что происходит внутри фреймворка и как можно выполнить задачу без него — еще лучше. Для некоторых задач использование фреймворков просто не оправдано.
Неужели в 2008м году кто-то все еще не знает, что
Это действительно JavaScript
dohlik, а мы, спустя 7 лет, в 2015 знаем что это JS. Правда, не все, но знаем =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько вещей об Ajax, которые должен знать веб-мастер