AJAX-вый бред в стиле WEB 2.0

Вчера на курсе XML мы разбирали обмен данными с сервером, то есть то, что сейчас обычно называется AJAX. Готовясь к занятию, я обычно стараюсь собрать разные дополнительные материалы для слушателей, и в этот раз я наткнулся на ряд статей по “соверменной технологии AJAX”. Более всего меня убила статейка, или даже так: веб-два-нулевый опус за авторством Александра Орлова. Самое ужасное не в том, что большая часть статьи – откровенная “пурга” и распространенные заблуждения, и даже не в том, что автор этого откровенно не понимает (и много еще чего), а в том, что так же считают подавляющее число Веб-мастеров. Сколько раз в конференции мне приходилось отвечать на вопросы и объяснять непотребность взятого из “авторитетных” статей и книжек кода! И как результат – совершенно непотребные, громоздкие и монстроподобные нелепые Веб-приложения.

Несколько цитат:

Википедия:
…Об AJAX заговорили после появления 18 февраля 2005 г. статьи Джесси Джеймса Гарретта (Jesse James Garrett) «Новый подход к веб-приложениям». AJAX — это не самостоятельная технология, а идея…

Правда? А до 2005 года ничего похожего не было? Или Дж. Дж. Гарретт, аки ветхозаветный пророк, прорубил скалу и дал воду жаждущим? Хотя статья г-на Гарретта весьма интересная, правильная и невероятно полезная для тех, кто решил заняться AJAX. Приведу одну цитату:

Что такое Ajax

Ajax – не технология. На самом деле это несколько технологий преуспевающих каждая в своей области, собранных в новое сильное направление. Ajax объединяет:

• стандартизованное представление с использованием XHTML и CSS;
• динамическое отображение и взаимодействие при помощи Document Object Model;
• обмен и управление данными через XML и XSLT;
• асинхронные получение данных с использованием XMLHttpRequest;
• и JavaScript, связывающий всё это воедино.

Запомним это. И смотрим далее, что нам пишет г-н Орлов:

Представьте себе, on-line игру “Морской бой”, в которую играют два закоренелых друга – житель ЮАР и житель Японии. Как с помощью такой модели сделать их игру максимально приятной? …

При обращении к серверу, генерируется страница, которая будет отображаться пользователю, и предлагать ему совершить интересующую его последовательность действий. При сознательном (хотя и не обязательно) выборе клиента, его запрос будет обращаться к AJAX модулю, который и будет производить все интересующие его вычисления и работу с сервером как таковым. Но в чем же новшество? Основное отличие в том что этот метод дает нам возможность динамически обращаться к серверу и выполнять интересующие нас действия. Например, нам нужно выполнить обращение к базе данных и получить интересующие нас данные которые затем будем использовать…

Однако не все так просто. Давайте теперь рассмотрим отрицательные черты.

Во-первых – мы можем передавать данные только методом GET, соответственно большие объемы данных придется оставить в покое. Данная проблема уже не раз поднималась в разных источниках, но господа, есть ведь Сookies, которые вполне приемлемы в случаях передачи больших данных, чем может вместить в себя GET запрос, а Javascript в свою очередь имеет функции для работы с ними…

И, наконец, защищенность. На этом остановимся поподробнее. Основная проблема заключается в том, что все данные и исходный код JavaScript функций можно увидеть путем просмотра исходного кода страницы, соответственно злоумышленник может проследить логику выполнения запросов и при определенном стечении обстоятельств выполнить необходимый ему набор команд. Это не играет особой роли, когда у нас идет простое сопоставление данных, но что делать в более сложных ситуациях, например при авторизации, и как в таком случае передавать пароли. Как уже было сказано выше, на помощь приходят Cookies. Необходимые данные можно пересылать с их помощью, так же их и обрабатывать. Возьмем пример, в котором пользователь будет проходить аутентификацию с помощью технологии которой посвящена статья.

Генерации страницы, мы формируем уникальные значения, которые затем помещаем в переменные сервера. И в Cookies браузера, затем при авторизации мы получаем имя пользователя и его пароль, которые нам необходимо передать модулю обработки на сервере.

После того как пользователь ввел данные и нажал кнопку Submit его пароль заноситься в Cookies, а имя пользователя передается открыто – ссылкой например http://www.mubestajax.com/ajax.php?login=pupkin при получении данных сервер, в первую очередь проводит сверку полученных данных. Так как значения которые мы генерировали с начала работы сервера а затем передавали их глобальным переменным сервера и cookies должны совпадать, то при проверке целостности переданных данных в случае несовпадения программа перестает работать. Если же все прошло хорошо, то извлекаются все необходимые данные и проводятся необходимые вычисления и работы. Такой способ защиты достаточно прост и эффективен…

Боже мой!!! Какой бред! И опять приходит на ум Булгаков: “Никогда не читайте советских газет!”. Ребята, никогда так не делайте!!! Это я про защищенность, а про “мы можем передавать данные только методом GET” – я вообще молчу…

Заметьте, изначальная идея Гаррета куда-то делась, и на ее смену пришел совершенно дикий код:

   // Input mode
    url  = 'http://localhost/xml/checkUserName.php?q=' + input;

То есть, от асинхронного обмена XML сообщениями (собственно AJAX, господа!) осталась только возможность запросить некие данные с помощью GET запроса. Воистину, сон разума рождает чудовищ!

А знаете, в чем самая большая проблема AJAX? В отсутствии стандартизации обмена меджу клиентом и сервером. В отсутствии единых принципов этого обмена! В том, что каждый раз этот обмен приходится писать заново. И всякие “AJAX фреймворки” – это лишь костыли! Вы просто выносите эту сизифову работу в тень, но не избавляетесь от нее…

Вчера на курсе мы попробовали одну идейку, которая позволяет однозначно специфицировать обмен данными в AJAX сценариях… Может быть, я соберусь и напишу статейки на этот счет. Как вы думаете, интересная это тема? Нужны вам материалы по этому?

Кстати, компьютерные технологии в обучении обсуждаются здесь.