Podam Wam teraz 3 znane przeze mnie metody obsługi ajaxa i powiem co wg mnie jest dobrym a co złym rozwiązaniem.

Sposób 1

W większości opisów i przykładów używanie ajaxa “kończy się” “osobnym bytem” w postaci pliku *.php znajdującego się gdzieś w katalogu publicznym:

/public
—/images
—/scripts
—/ajax
——/ajax_show_subcategories.php
——/ajax_check_email.php

Jest to najprostsze rozwiązanie ale jednocześnie najmniej efektywne. Po pierwsze każdy ajax to osobny plik który jakby “odcina” się od naszego systemu – czasami jest to pożądane ale w większości przypadków skrypt w ajaxie stanowi pewną funkcjonalność naszego systemu. Każdy z tych plików musi includować ręcznie jakieś pliki związane np z obsługą bazy danych, przetwarzać pliki konfiguracyjne itd itd. Jest to na pewno mało efektywne rozwiązanie ale na początek – zwłaszcza dla osób, które chcą się ajaxa dopiero nauczyć – rozwiązanie całkowicie wystarczające.

Zalety:
– prosty do zrobienia
– łatwy do przyswojenia

Wady
– mało wydajny
– nieefektywny
– nieelegancki
– sztucznie oddziela ajax’y od reszty systemu (tak jakby był w innym języku pisany)
– upublicznia kod (bo musi znajdować się w katalogu public)

Sposób 2

Ciekawszym i bardziej złożonym rozwiązaniem jest użycie tzw “ajax handlera”. Nie ma w tym nic rewolucyjnego. Cała idea polega na stworzeniu małego skryptu o dostępie publicznym który byłby pośrednikiem między odwołaniami do ajaxa a samymi skryptami ajaxowymi. Mówiąc prościej nie odwołujemy się bezpośrednio do skryptów ajaxowych tylko “prosimy” nasz ajax_handler aby dla nas jakis skrypt uruchomił. Przy czym skrypty ajaxowe mamy gdzieś schowane poza katalog publiczny – tak, że tylko ajax handler może je uruchomić. Ponadto do ajax_handlera możemy dodać od razu procedury które potrzebuje nasz program (np obsługa bazy danych) bez potrzeby dodawania ich do każdego skryptu oddzielnie.

/public
—/images
—/scripts
—/ajax_handler.php
/ajax
—/ajax_show_subcategories.php
—/ajax_check_email.php

Przykład: /ajax_handler?odpal_skrypt=ajax_show_subcategories.php

Rozwiązanie jest bardzo fajne ale… nie różni się ono ideowo od sposobu pierwszego. Jest to swego rodzaju “oszukaństwo” – po prostu zautomatyzowanie pewnych czynności i rozwiązanie kilku wyżej wymienionych wad – lecz nadal skrypty te stanowią odrębny byt i wymagają specjalnego traktowania. Podsumujmy.

Zalety
– Całkiem wydajny
– Ukrycie ajaxów z katalogu publicznego
– Dosyć elegancki (mydlenie oczu)

Wady
– Nieefektywny
– Sztucznie oddziela ajaxy od reszty systemu
– Wymaga stworzenia dodatkowego systemu (ajax_handler)
– Wywoływanie skryptów odbywa się w nienaturalny sposób

Sposób 3 – jak to zrobić w GRAD?

W frameworku GRAD proponuje podejść do problemu w zupełnie inny sposób. Metodą tę można zastosować także w innych aplikacjach ale wyjaśnię najpierw o co chodzi.

Odpowiedzmy sobie na pytanie: Czym jest program wywoływany w ajaxie?
Odpowiedź: Zwyczajnym skryptem PHP

Odpowiedzmy sobie na drugie pytanie: Czym jest program wywoływany w request?
Odpowiedź: Zwyczajnym skryptem PHP

Wniosek? Uruchamiajmy ajaxa po prostu jako zwyczajny request.

Jeżeli GRAD dzieli aplikację na kontrolery i akcję to nie ma znaczenia czy uruchomisz akcję wpisując w przeglądarce:

http://localhost/category/show

czy też uruchamiając w ajaxie (np z wykorzystaniem jQuery – albo twojej innej ulubionej metody uruchamiania ajaxów):

$.ajax({
url: “/category/show“,
dataType: “xml”,
success: function(xml) {
}
});

I już! To jaką metodę wybierzesz do uruchamiana ajaxów to juz jest Twoja wola. Różnica w całym podejściu polega na tym, żeby nie rozróżniać ajaxów na osobne pliki a traktować je jako naszą integralną część systemu. W ten sposób możemy wymazać pojecią “skrypty ajaxowe” bo każdy z twoich skryptów może być wywołany metodą ajaxową i każdy normalną metodą request w przeglądarce. Myślę, że na tym polega profesjonalne podejście do programowania dynamicznych, ciekawych i przede wszystkim spójnych stron w prosty i najbardziej naturalny sposób.

Zalety
– kod to kod, po co go rozróżniać?
– wybierasz metodę do skryptu a nie skrypt do metody
– eleganckie
– przejrzyste
– wydajne
– spójne

Wady
– Musisz zmienić sposób myślenia 🙂

To wszystko w tym artykule. Zachęcam gorąco do zabawy z moim frameworkiem – uważam, że naprawdę warto jeśli chcesz szybko i wydajnie skonstruować dynamiczną i wydajną stronę internetową.

Zobacz framework GRAD

Zachęcam gorąco do komentarzy na temat tego artykułu.

Pozdrawiam serdecznie.