AJAX

Коли існуючих можливостей ставати мало, а вдосконалювати існуюче вже нікуди, тоді і відбувається технологічний прорив. Таким проривом і є (Asynchronous JavaScript and XML) – підхід до побудови призначених для користувача інтерфейсів веб-додатків, при якому web-сторінка, не перезавантажуючись, сама довантажує потрібні користувачу дані. – один з компонентів концепції DHTML.

Що ж дає нам ця технологія. В даний час розробка WEB додатків прагне до розмежування клієнтської частини і серверної, цим і обумовлюється повсюдне використання шаблонів, таких як Smarty і XSLT. Зараз проекти стають складніше, і переплітати між собою різні технології ставати занадто дорого для часу розробника. Так, наприклад, всі стилі форматування виносяться в CSS або в XSL файли, HTML або XML дані зберігаються в інших розділах, серверні обробники в третіх, бази даних у четверті. І якщо ще 5-6 років тому практично скрізь можна було побачити переплетення всього цього в одному файлі, то зараз це все частіше ставати рідкістю.

При розробці більш складних проектів виникає необхідність у структурованості і легкості читання коду. Не слід засмічувати код програміста кодом верстальника, а код верстальника – правками дизайнера, і так далі.

Виникає необхідність в розмежуванні роботи. Так, наприклад, дизайнер буде робити свою роботу, верстальник свою, програміст свою, і при цьому ніхто один одному заважати не буде. У підсумку кожному учаснику проекту достатньо буде знати тільки ті дані, з якими йому доведеться працювати. У такому випадку продуктивність групи і якість проекту підвищується в рази. В даний час ця проблема з успіхом вирішується шляхом використання шаблонів, однак це теж створює певні труднощі, тому що щоб, скажімо, підключити Smarty, необхідно підключити програмний модуль обробки шаблонів, і чітко пов'язати зі структурою проекту. А це далеко не завжди можливо і вимагає певних витрат. Трохи простіше при використанні зв'язки XML + XSL, так як вони надають більше можливостей, однак це альтернатива, не більше. А що якщо подивитися в бік чогось радикально нового, що дозволяло б об'єднати все краще, використовуючи можливості того, що є? Спробуйте уявити JavaScript, який володіє всім можливостями PHP або Perl, включаючи роботу з графікою та базами даних, який має значно більш зручну розширюваність і практичність, і до того ж крос-платформі.

Так що ж таке ? Вперше про Ajax заговорили після появи в лютому 2005-го року статті Джесі Джеймса Гарретта (Jesse James Garrett) "Новий підхід до веб-додатків". Ajax – це не самостійна технологія. Це ідея, яка базується на двох основних принципах.

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

Використання XMLHttpRequest для звернення до сервера "на льоту".

Використання цих двох підходів дозволяє створювати набагато зручніші WEB-інтерфейси користувача на тих сторінках сайтів, де необхідна активна взаємодія з користувачем. Використання Ajax стало найбільш популярне після того, як компанія Google почала активно використовувати його при створенні своїх сайтів, таких як Gmail, Google maps і Google suggest. Створення цих сайтів підтвердило ефективність використання даного підходу.

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

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

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

Послідовність дій клієнта зберігається і він, швидше за все не зрозуміє того, що буде відбуватися, а слово буде асоціюватися тільки з назвою футбольного клубу. Але на стороні сервера все виглядає інакше.

При зверненні до сервера, генерується сторінка, яка буде відображатися користувачеві, і пропонувати йому зробити потрібну йому послідовність дій. При свідомому (хоча і не обов'язково) виборі клієнта, його запит буде звертатися до модулю, який і буде робити все цікавлять його обчислення і роботу з сервером як таким. Але в чому ж нововведення? Основна відмінність в тому що цей метод дає нам можливість динамічно звертатися до сервера і виконувати цікавлять нас дії. Наприклад, нам потрібно виконати звернення до бази даних і отримати цікаві для нас дані які потім будемо використовувати. Дані ми будемо зберігати в 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 отримали дуже широке поширення, тому що вони забезпечують простоту роботи при своїй невеликій ресурсоємності та достатньої надійності. А до рамках даного програмного забезпечення як не можна краще підійде рішення запропоноване вище.

У висновку хотілося б сказати, що з одного боку – величезний стрибок у WEB інженерії, але з іншого боку це давно назрівав етап еволюції, який відкрив нові горизонти в сфері розробки програмного забезпечення. У той же час ця технологія ще досить "сира" так як її використання на даний момент швидше приємне виключення. Але я впевнений, що про неї ще не раз всі почують.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*