Суть технологій ajax

AJAX — це не самостійна технологія, а швидше концепція використання декількох суміжних технологій. AJAX підхід до розробки призначених для користувача інтерфейсів комбінує кілька основних методів і прийомів:

•Використання DHTML для динамічної зміни змісту сторінки.

•Використання XMLHttpRequest для звернення до сервера «на льоту», не перезавантажуючи всю сторінку повністю

•Альтернативний метод — динамічне підвантаження коду JavaScript в тег <SCRIPT> з використанням DOM, що здійснюється із використанням формату JSON)

•Динамічне створення дочірніх фреймів

Використання цих підходів дозволяє створювати набагато зручніші веб-інтерфейси користувача на тих сторінках сайтів, де необхідна активна взаємодія з користувачем. AJAX — асинхронний, тому користувач може переглядати далі контент сайту, поки сервер все ще обробляє запит. Браузер не перезавантажує web-сторінку і дані посилаються на сервер без візуального підтвердження (крім випадків, коли ми самі захочемо показати процес з’єднання з сервером). Використання AJAX стало найпопулярніше після того, як компанія Google почала активно використовувати його при створенні своїх сайтів, таких як Gmail, Google Maps і Google Suggest. Створення цих сайтів підтвердило ефективність використання даного підходу.

Отже докладніше: якщо взяти класичну модель WEB-додатки:

Клієнт, набираючи в рядку пошуку адресу даного його ресурсу, потрапляючи на сервер, робить до нього запит. Сервер виробляє обчислення відповідно до запиту, звертається до бази даних і так далі, після чого отримані дані йдуть клієнтові і, в разі необхідності підставляються в шаблони і обробляються браузером. Результатом є сторінка, яку ми бачимо, і яку 80% населення країни знаходиться в WEB називають Інтернетом. Це класична модель, яка встигла себе зарекомендувати і заслужити собі почесне місце під сонцем. Це найпростіша модель взаємодії і, як наслідок, найпоширеніша. Однак її все частіше стає все менше і менше. Уявіть собі, on-line гру "Морський бій", в яку грають два закоренілих одного - житель ПАР і житель Японії. Як за допомогою такої моделі зробити їх гру максимально приємною? У будь-якому випадку дані потоплених кораблів будуть зберігається на сервері, і що б перевірити не походив чи опонент, необхідний буде кожен раз оновлювати сторінку і подгущать застарілі дані. "Але ж люди придумали кешування" - скажете ви і будете абсолютно праві, але легше від цього не стає. Кешування всього лише прискорить час взаємодії з сервером, але не позбавить від необхідності перезавантажувати сторінку. Як варіант можна поставити певний час самооновлення, але і в цьому випадку сторінка буде перезавантажуватися повністю.

Тепер подивимося на модель взаємодії AJAX:

Послідовність дій клієнта зберігається і він, швидше за все не зрозуміє того, що буде відбуватися, а слово AJAX буде асоціюватися тільки з назвою футбольного клубу. Але на стороні сервера все виглядає інакше.При зверненні до сервера, генерується сторінка, яка буде відображатися користувачу, і пропонувати йому зробити потрібну йому послідовність дій. При свідомому (хоча і не обов'язково) виборі клієнта, його запит буде звертатися до AJAX модулю, який і буде виробляти все цікавлять його обчислення і роботу з сервером як таким. Але в чому ж нововведення? Основна відмінність в тому що цей метод дає нам можливість динамічно звертатися до сервера і виконувати цікавлять нас дії. Наприклад, нам потрібно виконати звернення до бази даних і отримати цікавлять нас дані які потім будемо використовувати. Дані ми будемо зберігати в XML файлі який буде формуватися динамічно, таким чином:Створюємо новий об'єкт JavaScript:

var req = new ActiveXObject ("Microsoft.XMLHTTP"); (для IE)var req = new XMLHttpRequest (); (Для всього іншого)

Потім пишемо функцію використовуючи цей об'єкт

var req;

function loadXMLDoc(url) {

// branch for native XMLHttpRequest object

if (window.XMLHttpRequest) {

req = new XMLHttpRequest();

req.onreadystatechange = processReqChange;

req.open("GET", url, true);

req.send(null);

// branch for IE/Windows ActiveX version

} else if (window.ActiveXObject) {

req = new ActiveXObject("Microsoft.XMLHTTP");

if (req) {

req.onreadystatechange = processReqChange;

req.open("GET", url, true);

req.send();

}

}

}

Тепер HTML файлу пишемо скрипт, який буде:

function checkName(input, response)

{

if (response != ''){

// Response mode

message = document.getElementById('nameCheckFailed');

if (response == '1'){

message.className = 'error';

}else{

message.className = 'hidden';

}

}else{

// Input mode

url = 'http://localhost/xml/checkUserName.php?q=' \\

+ input;

loadXMLDoc(url);

}

}

У файлі localhost / xml / checkUserName.php ми обробляємо дані, отримані з командного рядка в даному випадку в змінної q. А результат зберігаємо в XML структурі, яку зберігаємо в цьому ж файлі. Так ми можемо отримати і обробити дані, отримані з БД, або що-небудь інше необхідне нам. До того ж сервер буде обробляти тільки ті дані, які нам необхідно оновити, а не всю сторінку в разі її перезавантаження.Тепер повернемося до двох друзів - любителям морського бою: з огляду на появу даного нововведення, ми можемо зробити наступне: поставити перевірку в плині кожних трьох секунд XML файлу дана перевірка на увазі під собою перевірку бази даних на предмет нового запису, тобто - зробленого опонентом ходу. Якщо хід був зроблений, сторінка без перезавантаження топить кораблі, тим самим, псуючи настрій учасникам водних баталій. Дана функціональність досягається елементарним використанням Javascript і таблиць стилів. Цей приклад досить наочний, однак далеко не повний, застосування даної технології набагато істотніше.Проте не все так просто. Давайте тепер розглянемо негативні риси.По-перше - ми можемо передавати дані тільки методом GET, відповідно великі обсяги даних доведеться залишити в спокої. Дана проблема вже не раз піднімалася в різних джерелах, але панове, є ж сookies, які цілком прийнятні у випадках передачі великих даних, ніж може вмістити в себе GET запит, а Javascript у свою чергу має функції для роботи з ними.Друга проблема - крос-браузерність. Об'єкт XMLHttpRequest ще не є частиною будь-якого стандарту (хоча щось подібне вже було запропоновано в специфікації W3C DOM Level 3 Load and Save). Тому існує два відмінних один від одного методу виклику цього об'єкта в коді скрипта. В Internet Explorer об'єкт ActiveX викликається так:

var req = new ActiveXObject("Microsoft.XMLHTTP");

У Mozilla і Safari це робиться простіше (так як там це об'єкт, вбудований в JavaScript):

var req = new XMLHttpRequest();

Всі сучасні браузери підтримують даний об'єкт і проблеми виникнуть лише в 1,8% користувачів (згідно даними статистики компанії SpyLog), які користуються дуже старими версіями браузерів, не підтримують цей об'єкт. І, нарешті, захищеність. На цьому зупинимося детальніше. Основна проблема полягає в тому, що всі дані і вихідний код JavaScript функцій можна побачити шляхом перегляду вихідного коду сторінки, відповідно зловмисник може простежити логіку виконання запитів і при певному збігу обставин виконати необхідний йому набір команд. Це не грає особливої ​​ролі, коли у нас йде просте зіставлення даних, але що робити в більш складних ситуаціях, наприклад при авторизації, і як у такому разі передавати паролі. Як вже було сказано вище, на допомогу приходять Cookies. Необхідні дані можна пересилати з їх допомогою, так само їх і обробляти. Візьмемо приклад, в якому користувач буде проходити аутентифікацію за допомогою технології якій присвячена стаття.

Генерації сторінки, ми формуємо унікальні значення, які потім поміщаємо в змінні сервера. І в Cookies браузера, потім при авторизації ми отримуємо ім'я користувача та його пароль, які нам необхідно передати модулю обробки на сервері. Після того як користувач ввів дані і натиснув кнопку Submit його пароль заноситися в Cookies, а ім'я користувача передається відкрито - посиланням наприклад http://www.mubestajax.com/ajax.php?login=pupkin при отриманні даних сервер, в першу чергу проводить звірку отриманих даних. Так як значення які ми генерували з початку роботи сервера а потім передавали їх глобальним змінним сервера і cookies повинні збігатися, то при перевірці цілісності переданих даних у разі неспівпадання програма перестає працювати. Якщо ж все пройшло добре, то витягуються всі необхідні дані і проводяться необхідні обчислення і роботи. Такий спосіб захисту досить простий і ефективний. Але для великих проектів він не підійде. Коли на перший план виходить безпечність, краще використовувати більш складні і надійні рішення. Але в більшості випадків даних заходів обережності буде більш ніж достатньо, так як використання більш складних модулів спричиняє за собою використання технологій які не завжди входять до складу стандартного програмного забезпечення сучасних серверів, основна риса яких - простота. Саме з цього такі технології як MySQL і PHP одержали дуже широке поширення, тому що вони забезпечують простоту роботи при своїй невеликій ресурсоємності та достатньої надійності. А до рамок даного програмного забезпечення як не можна краще підійде рішення запропоноване вище.