Sposób na AJAX’a
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ą.
Zachęcam gorąco do komentarzy na temat tego artykułu.
Pozdrawiam serdecznie.