Uwaga na AJAX

Jeśli przyszłością oprogramowania jest technologia AJAX, to mamy chyba do czynienia z największym wstecznictwem w historii informatyki. Nadzieja w tym, że ofiary tej zbiorowej aberracji w porę zorientują się, że skręciły w ślepą uliczkę.

Jeśli przyszłością oprogramowania jest technologia AJAX, to mamy chyba do czynienia z największym wstecznictwem w historii informatyki. Nadzieja w tym, że ofiary tej zbiorowej aberracji w porę zorientują się, że skręciły w ślepą uliczkę.

W artykule "Dziesięć lat w poczekalni" Tomasza Marcinka (CW 35/2005) pojawiła się teza, że przyszłością oprogramowania będzie AJAX. Jeśli tak rzeczywiście się stanie, w świecie produkcji oprogramowania znów zapanuje chaos. Ten sam, który dzięki różnym pożytecznym pomysłom i technologiom udało się w ostatnich latach w miarę opanować. Czym AJAX zasłużył sobie na miano technologii przyszłości? Czy na pewno jego zalety są godne jego ewidentnych wad? Spróbujmy rozważyć je po kolei.

Standard bez standardu

AJAX jest skrótem od Asynchronous JavaScript And XML, czyli zlepka technologii łączącego asynchroniczne wywołania (żądania przesyłane do serwera), JavaScript (język programowania) i XML (sposób zapisywania danych pobranych z serwera). Dzięki temu kod działający w przeglądarce może wysłać "w tle" żądanie do serwera, po czym być poinformowany o tym, kiedy dotrze wynik, by móc go przetworzyć używając JavaScript. Tak działa "od podszewki" interfejs sprawiający, że użytkownik pozornie nie czeka na pobranie danych lub wynik przeliczenia. Teoretyczna koncepcja jest słuszna - na pewno taki interfejs jest wygodny i łatwy w użyciu, a użytkownik się nie irytuje.

Główny problem z AJAX-em to druga literka w jego nazwie, czyli JavaScript. Jest to język opracowany przez Netscape w 1995 r., który doczekał się później odpowiednika w postaci JScript dla przeglądarki Internet Explorer. Potem były już kolejne standardy ECMA. Najnowszy standard to JavaScript 1.6 - ECMA-262 Edition 3. Równocześnie dostępny jest ECMA-357 - standard określający to, w jaki sposób XML powinien być obsługiwany z poziomu JavaScript.

JavaScript jest językiem bazującym na prototypach, bez silnej kontroli typów w ogólności i bez możliwości definiowania obiektów z określonymi typami w szczególności itp. Nie przeszkadza mu to jednak być najczęściej stosowanym dialektem do manipulacji tzw. DOM (Document Object Model), czyli hierarchii obiektowej pozwalającej na dostęp do elementów strony i okna przeglądarki.

Mechanizm wykorzystywany jest także przy tworzeniu niektórych witryn pishingowych - bo łatwo tam można "ukryć" elementy, które pokazywałyby, że jest to fałszywka. Na szczęście producenci przeglądarek coraz bardziej ograniczają wykorzystanie DOM, tak by jednak było widać, że jest to okno wygenerowane z kodu JavaScript.

W3C opracowało wprawdzie standard DOM, ale jak zwykle różne przeglądarki różnie go implementują. Nawet więc wydawałoby się proste operacje muszą być w specjalny sposób "obudowywane", by kod mógł działać mniej więcej podobnie na najważniejszych platformach w każdych warunkach. To samo, niestety, dotyczy każdego innego kodu JavaScript.

Duża odporność na testy

Zadowolenie użytkownika z aplikacji, choć ważne, nie może przesłaniać innych spraw. Śledzenie JavaScript jest wyzwaniem samym w sobie. Z uwagi na typy i inne cechy języka 99% błędów jest widocznych dopiero po uruchomieniu kodu. Kompilator (w tym przypadku raczej analizator) może znaleźć wyłącznie proste błędy składniowe. Co prawda IDE może "podpowiadać" składowe elementy obiektu (i tak się w przypadku wielu produktów dzieje), ale to jest tylko ułatwienie pisania - i tak podczas uruchomienia może wystąpić błąd niezwiązany ze składnią. Przykładowo, wykonywanie JavaScript na platformie Windows zależy od kilku komponentów ActiveX (w tym kluczowego dla AJAX - XMLHttpRequest, pozwalającego na pobieranie danych w tle). Każdy z tych komponentów może być w innej wersji, co przekłada się na "drobne" różnice we właściwościach.

Technologia AJAX zakłada, że dane są pobierane z serwera w formacie XML. Kod JavaScript w przeglądarce dokonuje następnie wybrania właściwych informacji do wyświetlenia. Najlepiej jest przyjrzeć się fragmentowi kodu wywoływanego po stronie klienta, gdy strumień danych XMLHttpRequest jest już pobrany: var xmldoc = http_request.responseXML; var element = xmldoc.getElementsByTagName('phone').item(0).

XML o określonej strukturze jest pobierany z serwera, umieszczany w obiekcie zgodnym z XmlDocument; potem należy odwołać się do konkretnego pola... tylko że JavaScript nie zna typów, które są oczywistością dla programistów C/C++/Java/C#. W tym kontekście JavaScript bardziej przypomina Visual Basic, ale w starej wersji, w której mieliśmy tylko ogólny typ "obiekt", którego właściwości były wywoływane przy użyciu tzw. późnego wiązania. Sprawdzanie tego, czy "to co jest po kropce" może być wykonane, odbywało się dopiero w trakcie działania programu - co w kilku specyficznych przypadkach jest może przydatne, ale na pewno nie ułatwia bezbłędnego pisania kodu.

Odwołując się do powyższego przykładowego kodu, ponieważ nie dało się wygenerować struktury do obsługi strumienia XML, trzeba dodatkowo wskazać nazwę elementu. A co jeżeli programista pomyli się i napisze "fhone"? Ten błąd zostanie wykryty dopiero wtedy, gdy dana instrukcja będzie wykonana w przeglądarce. Co więcej, w JavaScript nie ma możliwości stworzenia testu jednostkowego. Ani sam język, ani dostępne dziś narzędzia deweloperskie nie pozwalają na takie programowanie. Jedyna alternatywa to mniej lub bardziej zautomatyzowane "klikanie".

Ci, którzy mieli okazję tworzyć testy dla większych aplikacji, wiedzą jak trudno sprawić, by w ramach testów funkcyjnych pokryć (czyli sprawdzić) 100% kodu źródłowego aplikacji, tak żeby każda instrukcja była wykonana co najmniej raz, a najlepiej tyle razy, ile jest możliwych sposobów dojścia do danej funkcjonalności. W przypadku aplikacji WWW oznacza to testowanie na wielu przeglądarkach, bo część składni JavaScript/odwołań do DOM będzie różna dla różnych przeglądarek/wersji przeglądarek. Proszę sobie wyobrazić testy naprawdę skomplikowanej aplikacji w JavaScript - to istny koszmar!

Oczywiście w modelu AJAX duża część logiki działa po stronie serwera, ale za całą interakcję z użytkownikiem odpowiada kod interpretowany w przeglądarce.

W niektórych przypadkach można użyć arkuszy stylów XSL(T), ale tylko do formatowania i prezentacji wyników. Problem pojawia się także wtedy, gdy trzeba obsłużyć błąd, np. błąd pamięci. Nowsze wersje JavaScript mają mechanizm try/catch, ale nie ma standardowej możliwości sprawdzenia typu wyjątku - wszystko zależy od przeglądarki.

W poszukiwaniu unikalności

Czy AJAX jest w jakikolwiek sposób lepszy, niż inne technologie? Głównym jego zadaniem jest zmiana sposobu interakcji z aplikacją - brak czasu "zamrożenia", gdy klient pobiera dane z serwera. Pewne operacje są wykonywane w tle, a równocześnie użytkownik może normalnie pracować. Ale podobny efekt można uzyskać, stosując tzw. HTTP partial caching - czyli mechanizm, w którym tylko część strony pobierana jest z serwera WWW, a reszta z lokalnego bufora przeglądarki. Przykładowo, lokalnie można przechowywać nagłówki, pola do filtrowania, a z serwera pobierać jedynie dane do wypełnienia siatki tabeli.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200