Dziudek's jogger

Każdy kto programował w JavaScript przyzwyczaił się zapewne do zdarzenia onLoad występującego w momencie załadowania się danej strony WWW. Z reguły wraz z tym zdarzeniem swoje działanie rozpoczynały wszelkie skrypty JS związane z DOM, bo wywołanie ich wcześniej niechybnie skończyłoby się błędem związanym z odwoływaniem do elementu, który jeszcze w DOM nie istnieje.

Dlaczego używać DomReady ?

Nie ma co ukrywać, że w wypadku stron bogatych w grafikę oczekiwanie na wystąpienie zdarzenia onLoad wymagało cierpliwości (wprost proporcjonalnej do ilości grafiki). Na nasze szczęście stworzono zdarzenie DOMContentLoaded - występuje ono w momencie załadowania kompletnego drzewa dokumentu - zatem znacznie wcześniej niż zdarzenie onLoad, bo zdarzenie DOMContentLoaded nie jest zależne od ilości grafiki - w skrajnych wypadkach może więc ono wystąpić kilkanaście sekund przed zdarzeniem onLoad.

Znów ta kompatybilność

Żeby nie było tak słodko jak się niektórym wydaje, to muszę tu wspomnieć o tym co jest największą bolączką JS - jak zwykle wszystko zależy od przeglądarki - zdarzenie DOMContentLoaded zadziała na Firefoksie (i oczywiście wszelkich bazowanych na Gecko przeglądarkach) i Operze (wersje od 9.0 w górę), w wypadku IE trzeba zastosować tą metodę, natomiast Safari i Konqueror wymagają sprawdzania właściwości document.readyState (choć ostatnie wersje Safari wspierają natywnie zdarzenie DOMContentLoaded i kilka innych zdarzeń DOM) - czyli sprawa się ma niewiele lepiej niż w IE. Dociekliwych tego jak to dokładnie działa odsyłam do wpisu Riddle'a, który opisał całość dokładnie - ewentualnie można obejrzeć implementacje w MooTools czy jQuery. Całe szczęście, że ilość przeglądarek zupełnie nie mających szansy na obsługę DOMContentLoaded ociera się o błąd statystyczny (no chyba, że macie dziwną grupę docelową) ;).

Pora więc pokazać jak to się robi w MooTools:

window.addEvent("domready", function(){
    // wszystko tutaj wykona się po załadowaniu DOM
});

Powyższy kod to właściwie jeden z tych fragmentów, który pojawia się bardzo często w każdym skrypcie pisanym z użyciem MooTools, dlatego jak ktoś ma słabą pamięć to warto go sobie gdzieś zachować/powiesić na ścianie/[inna forma wspomagania zawodnej pamięci].

Dlaczego warto stosować DOMContentLoaded ?

Teraz pora na opisanie kilku zastosowań tego cudownego zdarzenia ;)

• Czasem w życiu bywa tak, że któraś z nowoczesnych przeglądarek podczas renderowania strony coś psuje - o ile w IE mamy do dyspozycji Expressions (tu znów odsyłam do Riddle'a) w Firefoksie mamy ostatecznie do dyspozycji XBL o tyle dla Opery i Safari nie znam żadnych cudownych metod uzdrawiania tego co wyświetli silnik przeglądarki (a może wiecie coś czego ja nie wiem ? Komentarz mile widziany :). Dlatego też wykorzystując obiekt Browser możemy stwierdzić z kim mamy do czynienia (z jaką przeglądarką) i poprawić to i owo, a dzięki zdarzeniu DOMContentLoaded, zmiany pojawią się (z reguły) o wiele wcześniej niż cała strona.
• Nie muszę chyba nikomu mówić, że możliwość wykonania jakiejś operacji przed załadowaniem całej strony (która może być tylko jedną z podstron na drodze do celu) jest dla użytkownika bezcenna - dlatego dodanie zdarzeń do elementów strony zawsze powinno następować jak najszybciej, tak aby użytkownik mógł być pewien, że widząc jakiś przycisk po jego kliknięciu uzyska wykonanie oczekiwanej operacji zamiast braku jakiejkolwiek reakcji.
• W pewnych specyficznych sytuacjach (strony statyczne) możemy symulować takie efekty jak wybór stylu strony - wraz z dokumentem ładujemy wspólną część dla wszystkich styli, a wraz ze zdarzeniem DOMContentLoaded analizujemy zawartości ciasteczek (Cookies) i na tej podstawie "doładowujemy" (przydatny tu będzie plugin Assets) dodatkowy, określony przez użytkownika styl. Może całość jest trochę naciągana, ale gdy nie ma żadnego języka server-side pod ręką trzeba sobie jakoś radzić :)

Ostrożność to podstawa

Na koniec jeszcze jedna istotna uwaga związana ze zdarzeniem DomReady w MooTools. Zdarzyło mi się kilka przypadków, kiedy to w IE występowały problemy - było to prawdopodobnie związane z dużym stopniem skomplikowania stron na których występował problem. Okazywało się bowiem, że zdarzenie to występowało przed załadowaniem całego drzewa DOM. Co polecam ? W miarę możliwości podczas procesu tworzenia skryptu bazować na zdarzeniu onLoad, natomiast na sam koniec spróbować je zamienić na zdarzenie DomReady i dokładnie zbadać zachowanie skryptu w IE. Pozwoli to uniknąć błędów, które można powiedzieć biorą się z kosmosu - skrypt "nie widzi" elementów strony, które są załadowane itp.

Podsumowanie

O zdarzeniach w MooTools 1.2 wiemy już właściwie wszystko co nam potrzeba - zarówno od strony klasy Element, jak i od strony klasy Events i obiektu Event. W następnych częściach kursu niewątpliwie wykorzystamy tą wiedzę by manipulować strukturą drzewa dokumentu.