ActionWeb. Асинхронный интернет.
С момента первого упоминания об AJAX в статье Джесси Джеймса Гарретта «Новый подход к разработке веб- приложений» 18 февраля 2005 года прошло уже 4 года. За это время наверно каждый веб- разработчик хоть раз испробовал эту технологию.
Но почему до сих пор подавляющее большинство разрабатываемых веб- сайтов придерживаются стандартной модели загрузки контента и не перешли полностью на AJAX платформу?
читать дальше >>
|
Статья интересная, спасибо.
Но, если честно, то вводить еще одно новое понятие поверх AJAX-а как-то... слишком что ли. Как мне кажется, люди, которые разрабатывают веб-приложения на высоком уровне, изначально все это принимают во внимание (индексация поисковиками, интеграция с браузером и т.д.).
Да, меня самого мучили сомнения по поводу необходимости введения нового термина (ActionWeb), просто столкнувшись с созданием сайтов, работающих без перезагрузки страницы, я понял, что основная работа над ними заключается не в наладке AJAX запросов (тут как раз всё довольно просто), а в решении описанных в статье проблем. После этого называть такие сайты просто "AJAX сайты" я посчитал несколько несправедливым, прежде всего, по отношению к труду разработчика. Я не Гаретт, я не претендую на новаторство, но мне кажется, называть ActionWeb приложения "сайтами, работающими на AJAX" это всё равно, что назвать Bentley "машиной с двигателем внутреннего сгорания". Но это только моё мнение и вашу критику я признаю засчитанной.
в dojo Back - Forward , как и все остальное, работает безукоризненно, (в отличие от jQuery)
Очень забавно, когда ничего не понимающие люди ставят вердикт в подобной интонации
А ответьте ув. Гость, что такое Dojo? Какой спектр задач покрывает эта бибилиотека? А потом возьмите листочек и выпишите что из Dojo есть в jQ. Как в библиотеке может быть реализовано то, что ей не требуется?
У меня машина без крыльев в отличие от самолета, мне теперь ей не пользоваться?
когда мне надоело выискивать и обходить баги jQuery, я перешел на Dojo, и с тех пор - никаких проблем.
Молодетс. Возьми с полки пирожок.
Я думаю, что этот термин не отражает действительности. Я бы сказал, что это просто сайт на AJAX. И вообще, на мой взгляд, статья слишком запутанна.
Я бы объяснил все несколько проще.
Задача: Сделать сайт на AJAX.
Создаем обычный сайт, к примеру, на php. Если JS включен, он берет на себя дальнейшее управление всеми действиями пользователя. И тут же перехватывает все действенные элементы (ссылки, формы и т.д.). Если к PHP странице происходит обращение с выполнением такого условия:
то будет возвращен нужный контент, если нет, вернется обычная страница.
Остальные проблемы (закладки, навигация браузером) уже не столь значимы, ведь можно сделать кнопку "создать закладку", так же как вы предлагаете сделать дубликат навигации браузера.
С точки зрения серверной части, работы там действительно не намного больше. Основные сложности как раз ложатся на "Если JS включен, он берет на себя дальнейшее управление всеми действиями пользователя". Представим ситуацию, когда на наш "сайт на AJAX" (как вы выразились) захотят по ссылке mysute.ru/articles/page10/. При этом /articles/ - пункт меню первого уровня, /page10/ - меню второго уровня (банальная постраничная навигация). Какие основные действия нужно сделать клиентскому скрипту?
1. сделать редирект с mysute.ru/articles/page10/ на mysute.ru#/articles/page10/
2. находясь на mysute.ru#/articles/page10/ обработать location.hash, понять, какой пункт меню первого уровня подсвечивать
3. запросить через AJAX у сервера контентную страницу /articles/page10/
4. отработать анимацию перехода, отобразить контейнер с постраничной навигацией
5. обработать меню второго уровня (постраничную навигацию), понять какой пункт подсвечивать, подсветить нужный пункт (/articles/page10/)
6. если нужно, отработать анимацию перехода для меню второго уровня, отобразить контент (собственно десятую страницу статей)
А с тем, что закладки и навигация браузером не столь значима, я согласен.
То, что Вы проделали большую работу, я согласен. Кстати, я более детально изучил Ваши сайты - снимаю шляпу.
Признаю, статья хороша, но все же, не соглашусь с данным термином, ведь AJAX это аббревиатура, а здесь полноценное название, как у технологии - вводит в заблуждение. Что-то, вроде RIAJS или JSRIA было бы более уместно. Ну, или не знаю, что-то более отражающее действительность.
Кстати, не обязательно каждый раз делать редирект. URL можно использовать только в качестве точки в хода, а навигацию по страницам опять-таки отдать JS.
Пункты 1,2,3 в таком случае не нужны, а пункты 4,5,6 не имеют отношения к задаче, это всего лишь мишура.
Если не прав, поправьте.
Если URL использовать в качестве точки входа и не делать редирект, тогда зайдя на сайт по определённой ссылке (допустим mysite.ru/articles/actionweb/) и походив по нему мы можем получить в адресной строке что-нибудь вроде mysite.ru/articles/actionweb/#/news/page1/ - а это, согласитесь, совсем не фэншуй. Редирект будет срабатывать только если пользователь изначально попал не на главную страницу, т.е с mysite.ru/articles/actionweb/ редирект на mysite.ru/#/articles/actionweb/ и дальше уже нормально работаем с location.hash
Пункты 4, 5, 6 перестают быть мишурой и превращаются в серьёзную головную боль как только становятся частью ТЗ
RIAJS - почему бы и нет, вполне мило звучит, только по-моему тоже не отражает суть. Термин RIA (Rich Internet Application) сам по себе не исключает перезагрузку страницы. Вообще я не делаю акцента на новом названии и на новом термине, хотите называть это "AJAX сайтами" - пожалуйста
Отправить комментарий
Приветствуются комментарии:- Полезные.
- Дополняющие прочитанное.
- Вопросы по прочитанному. Именно по прочитанному, чтобы ответ на него помог другим разобраться в предмете статьи. Другие вопросы могут быть удалены.
P.S. Лучшее "спасибо" - не комментарий, как все здорово, а рекомендация или ссылка на статью.Для остальных вопросов и обсуждений есть форум.