Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
01278 012080 11047022 na godz. na dobę w sumie
Ajax dla zaawansowanych. Architektura i najlepsze rozwiązania - książka
Ajax dla zaawansowanych. Architektura i najlepsze rozwiązania - książka
Autor: Liczba stron: 392
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-1585-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> ajax
Porównaj ceny (książka, ebook, audiobook).
Dowiedz się:

Ajax (skrót od ang. Asynchronous JavaScript and XML) to niezwykle popularna technologia tworzenia serwisów internetowych, w której połączono kilka sprawdzonych technik. Dzięki tej zintegrowanej technologii do niezbędnego minimum została ograniczona ilość danych przesyłanych pomiędzy serwerem a oknem przeglądarki użytkownika. Nie tylko to przysporzyło Ajaksowi zwolenników -- jest on także bardzo dobrym narzędziem do tworzenia interaktywnych serwisów internetowych. Sprawdza się również przy przeprowadzaniu weryfikacji danych oraz rysowaniu wykresów w czasie rzeczywistym. Dzięki asynchronicznym wywołaniom umożliwia szybszą interakcję z użytkownikiem, a poszczególne sekcje mogą być wywoływane indywidualnie, dzięki czemu aplikacja sprawia wrażenie bardziej dynamicznej.

Książka 'Ajax dla zaawansowanych. Architektura i najlepsze praktyki' to idealna lektura dla programisty, który miał już przyjemność pracować z Ajaksem. Podjęto tu wszystkie zagadnienia niezbędne do tworzenia dynamicznych aplikacji, niezależnie od użytych narzędzi i technologii. Na praktycznych przykładach przedstawiono sposoby wykorzystania Ajaksa do tworzenia rozbudowanych interfejsów w przeglądarce dla aplikacji internetowych, ze szczególnym uwzględnieniem ich uniwersalności, możliwości wielokrotnego wykorzystania kodu, skalowalności oraz łatwości eksploatacji. Podręcznik wskazuje zarówno sytuacje, w których Ajax jest przydatny, jak i takie, w których jego wybór nie spełni oczekiwań użytkownika.

Poznaj więcej niezwykłych możliwości Ajaksa!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Ajax dla zaawansowanych. Architektura i najlepsze rozwi„zania Autor: Shawn M. Lauriat T‡umaczenie: Rados‡aw Meryk ISBN: 978-83-246-1585-8 Tytu‡ orygina‡u: Advanced Ajax: Architecture and Best Practices Format: 168x237, stron: 392 Dowiedz siŒ: (cid:149) Jak tworzy(cid:230) rozbudowane i idealnie dopasowane do potrzeb interfejsy? (cid:149) Jak zapewni(cid:230) uniwersalno(cid:156)(cid:230), skalowalno(cid:156)(cid:230) oraz ‡atwo(cid:156)(cid:230) eksploatacji? (cid:149) Jak zaprojektowa(cid:230) architekturŒ aplikacji? Ajax (skr(cid:243)t od ang. Asynchronous JavaScript and XML) to niezwykle popularna technologia tworzenia serwis(cid:243)w internetowych, w kt(cid:243)rej po‡„czono kilka sprawdzonych technik. DziŒki tej zintegrowanej technologii do niezbŒdnego minimum zosta‡a ograniczona ilo(cid:156)(cid:230) danych przesy‡anych pomiŒdzy serwerem a oknem przegl„darki u¿ytkownika. Nie tylko to przysporzy‡o Ajaksowi zwolennik(cid:243)w (cid:151) jest on tak¿e bardzo dobrym narzŒdziem do tworzenia interaktywnych serwis(cid:243)w internetowych. Sprawdza siŒ r(cid:243)wnie¿ przy przeprowadzaniu weryfikacji danych oraz rysowaniu wykres(cid:243)w w czasie rzeczywistym. DziŒki asynchronicznym wywo‡aniom umo¿liwia szybsz„ interakcjŒ z u¿ytkownikiem, a poszczeg(cid:243)lne sekcje mog„ by(cid:230) wywo‡ywane indywidualnie, dziŒki czemu aplikacja sprawia wra¿enie bardziej dynamicznej. Ksi„¿ka (cid:132)Ajax dla zaawansowanych. Architektura i najlepsze praktyki(cid:148) to idealna lektura dla programisty, kt(cid:243)ry mia‡ ju¿ przyjemno(cid:156)(cid:230) pracowa(cid:230) z Ajaksem. PodjŒto tu wszystkie zagadnienia niezbŒdne do tworzenia dynamicznych aplikacji, niezale¿nie od u¿ytych narzŒdzi i technologii. Na praktycznych przyk‡adach przedstawiono sposoby wykorzystania Ajaksa do tworzenia rozbudowanych interfejs(cid:243)w w przegl„darce dla aplikacji internetowych, ze szczeg(cid:243)lnym uwzglŒdnieniem ich uniwersalno(cid:156)ci, mo¿liwo(cid:156)ci wielokrotnego wykorzystania kodu, skalowalno(cid:156)ci oraz ‡atwo(cid:156)ci eksploatacji. PodrŒcznik wskazuje zar(cid:243)wno sytuacje, w kt(cid:243)rych Ajax jest przydatny, jak i takie, w kt(cid:243)rych jego wyb(cid:243)r nie spe‡ni oczekiwaæ u¿ytkownika. (cid:149) Planowanie interfejs(cid:243)w Ajaksa (cid:149) Debugowanie, walidacja i optymalizacja kodu (cid:149) Tworzenie skalowalnych interefejs(cid:243)w (cid:149) Architektura aplikacji po stronie serwera oraz klienta (cid:149) Bezpieczeæstwo aplikacji internetowych (cid:149) Projektowanie gier Poznaj wiŒcej niezwyk‡ych mo¿liwo(cid:156)ci Ajaksa! Wydawnictwo Helion ul. Ko(cid:156)ciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Spis treści Podziękowania ............................................................................................................................... 11 O autorze ......................................................................................................................................... 13 Wprowadzenie ...................................................................................................... 15 0.1. Ajax — znaczenie skrótu ............................................................................. 16 0.1.1. Asynchroniczny ................................................................................ 17 0.1.2. JavaScript ........................................................................................... 17 0.1.3. XML .................................................................................................... 18 0.2. Cele niniejszej książki .................................................................................. 19 0.3. Wymagania wstępne potrzebne do studiowania tej książki ................. 23 Rozdział 1. Użyteczność ........................................................................................................... 27 1.1. Interfejs czy pokaz ........................................................................................ 28 1.1.1. Implementacja .................................................................................. 30 1.2. Oczekiwania użytkowników ...................................................................... 32 1.3. Wskaźniki i inne formy kontaktu z użytkownikami .............................. 34 1.3.1. Throbber ............................................................................................ 34 1.3.2. Wskaźniki postępu ........................................................................... 37 1.3.3. Komunikaty dla użytkowników wyświetlane w pętli ............... 40 1.4. Znaczniki semantyczne ............................................................................... 47 1.4.1. Lepsza dostępność ........................................................................... 48 1.4.2. Łatwość użytkowania ...................................................................... 50 5 6 Spis treści 1.4.3. Łatwiejsza pielęgnacja .....................................................................51 1.4.4. Łatwiejsze przetwarzanie ................................................................52 1.5. Co łączy style CSS z językiem JavaScript ..................................................55 Rozdział 2. Dostępność ..............................................................................................................61 2.1. Wymagania WCAG i wytyczne sekcji 508 ................................................62 2.1.1. WCAG .................................................................................................63 2.1.2. Wytyczne sekcji 508 ..........................................................................71 2.2. Czytniki ekranu mogą obsługiwać wywołania Ajax ...............................73 2.2.1. Zastępowanie treści ..........................................................................74 2.2.2. Walidacja formularzy .......................................................................75 2.3. Dyskretny Ajax ..............................................................................................77 2.4. Projektowanie z uwzględnieniem zasad dostępności ............................79 2.4.1. Projektowanie aplikacji o wysokim kontraście ............................79 2.4.2. Interfejs z możliwością powiększania fragmentów ekranu .......81 2.4.3. Kontrolki, do których łatwo dotrzeć ..............................................83 2.5. WAI-ARIA .......................................................................................................84 Rozdział 3. Architektura aplikacji po stronie klienta .........................................................87 3.1. Obiekty i wyzwalanie zdarzeń ...................................................................88 3.1.1. Obsługa zdarzeń obiektów wbudowanych ..................................90 3.1.2. Obiekty JavaScript ............................................................................92 3.2. Wzorzec projektowy Model-Widok-Kontroler ......................................108 3.2.1. Model ................................................................................................109 3.2.2. Widok ................................................................................................113 3.2.3. Kontroler ..........................................................................................122 3.3. Projektowanie aplikacji sterowanych zdarzeniami ...............................125 3.3.1. Zalety wykorzystanej architektury ..............................................126 Rozdział 4. Debugowanie kodu po stronie klienta ........................................................... 129 Spis treści 7 4.1. Walidacja, walidacja, walidacja ................................................................ 130 4.1.1. Walidator zestawu znaczników ................................................... 132 4.1.2. Walidator CSS ................................................................................. 133 4.1.3. Ekstraktor semantyczny ................................................................ 134 4.2. Narzędzia w przeglądarkach i wtyczki .................................................. 135 4.2.1. Konsola ............................................................................................. 135 4.2.2. Internet Explorer ............................................................................ 136 4.2.3. Firefox ............................................................................................... 141 4.2.4. Opera ................................................................................................ 147 4.2.5. Safari ................................................................................................. 149 4.3. Profilowanie kodu JavaScript ................................................................... 152 4.3.1. Rozpoznawanie „wąskich gardeł” ............................................... 154 4.4. Testy jednostkowe ...................................................................................... 158 4.4.1. Asercje .............................................................................................. 160 4.4.2. Konfiguracja testu .......................................................................... 161 4.4.3. Właściwy test .................................................................................. 164 4.4.4. Obiekty-atrapy ................................................................................ 166 4.4.5. Zestawy testów ............................................................................... 169 Rozdział 5. Optymalizacja wydajności ................................................................................ 173 5.1. Wydajność bazy danych ........................................................................... 174 5.1.1. Schemat ............................................................................................ 175 5.1.2. Zapytania ......................................................................................... 179 5.2. Zajętość pasma i opóźnienia ..................................................................... 181 5.2.1. Pasmo ............................................................................................... 183 5.2.2. Opóźnienia ...................................................................................... 187 8 Spis treści 5.3. Pamięć podręczna .......................................................................................190 5.3.1. System plików .................................................................................191 5.3.2. Pamięć ...............................................................................................193 5.3.3. Uzupełnienie implementacji .........................................................200 5.4. Wykorzystanie HTTP/1.1 ...........................................................................202 5.4.1. If-Modified-Since ............................................................................205 5.4.2. Range ................................................................................................206 5.5. Profilowanie kodu PHP .............................................................................209 5.5.1. Debuger APD ...................................................................................209 5.5.2. Xdebug ..............................................................................................213 Rozdział 6. Skalowalne i łatwe do pielęgnacji aplikacje Ajaksa ....................................219 6.1. Ogólne praktyki ..........................................................................................220 6.1.1. Użycie procesora .............................................................................221 6.1.2. Zużycie pamięci ..............................................................................223 6.2. Wiele prostych interfejsów ........................................................................227 6.2.1. Modularność ....................................................................................227 6.2.2. Późne ładowanie .............................................................................230 6.3. Rozbudowane interfejsy ............................................................................233 6.3.1. Aplikacje monolityczne ..................................................................233 6.3.2. Wstępne ładowanie ........................................................................237 Rozdział 7. Architektura aplikacji po stronie serwera ......................................................239 7.1. Projektowanie aplikacji dla wielu interfejsów .......................................240 7.2. Wzorzec projektowy Model-Widok-Kontroler ......................................244 7.2.1. Model ................................................................................................244 7.2.2. Kontroler ..........................................................................................254 7.2.3. Widok ................................................................................................263 7.3. Wykorzystanie wzorca Fabryka wraz z mechanizmem obsługi szablonów ..............................................269 Rozdział 8. Bezpieczeństwo aplikacji internetowych ...................................................... 275 Spis treści 9 8.1. HTTPS .......................................................................................................... 277 8.1.1. Po co używać HTTPS? ................................................................... 277 8.1.2. Bezpieczeństwo a wydajność ....................................................... 279 8.2. Ataki typu SQL Injection .......................................................................... 280 8.2.1. Nie używaj opcji magic_quotes ................................................... 281 8.2.2. Filtrowanie ....................................................................................... 282 8.2.3. Instrukcje preparowane ................................................................ 284 8.3. XSS ................................................................................................................ 285 8.3.1. Unieszkodliwianie zestawu znaczników ................................... 286 8.3.2. Unieszkodliwianie adresów URL ................................................ 291 8.4. CSRF ............................................................................................................. 292 8.4.1. Sprawdzanie adresu, z którego pochodzi żądanie ................... 294 8.4.2. Przesyłanie dodatkowego nagłówka .......................................... 296 8.4.3. Pomocnicze, losowe tokeny .......................................................... 297 8.5. Nie ufaj użytkownikowi ............................................................................ 300 8.6. Nie ufaj serwerowi ..................................................................................... 302 Rozdział 9. Dokumentacja ..................................................................................................... 307 9.1. Dokumentowanie kodu jest potrzebne .................................................. 308 9.1.1. Odtwarzanie projektu we własnej pamięci ............................... 308 9.1.2. Ułatwienie nauki ............................................................................ 310 9.1.3. Uważajcie na autobusy .................................................................. 311 9.2. Dokumentowanie interfejsu API ............................................................. 311 9.2.1. phpDocumentor ............................................................................. 312 9.2.2. JSDoc ................................................................................................ 320 10 Spis treści 9.3. Wewnętrzna dokumentacja programisty ...............................................325 9.3.1. Standardy kodowania ....................................................................327 9.3.2. Przewodniki programowania .......................................................332 9.3.3. Przewodniki stylu ...........................................................................333 Rozdział 10. Projektowanie gier ..............................................................................................335 10.1. Inny rodzaj bezpieczeństwa ......................................................................337 10.1.1. Walidacja ..........................................................................................338 10.1.2. Logika serwerowej strony aplikacji .............................................340 10.2. Pojedynczy gracz ........................................................................................343 10.2.1. Podwójne buforowanie ..................................................................343 10.3. Tryb czasu rzeczywistego — wielu graczy .............................................348 10.3.1. Odpowiedzi w postaci strumieni .................................................349 10.3.2. Element event-source grupy WHATWG ....................................354 10.3.3. Animacje z wykorzystaniem technik przewidywania ..............356 Rozdział 11. Wnioski .................................................................................................................359 11.1. Pamiętaj o użytkownikach ........................................................................360 11.2. Projektuj z myślą o przyszłości .................................................................361 11.3. Programuj z myślą o przyszłości ..............................................................362 Bibliografia ...................................................................................................................................365 Dodatek A Zasoby ....................................................................................................................369 Dodatek B OpenAjax ..............................................................................................................373 Zgodność ze standardem ....................................................................................374 Rejestracja przestrzeni nazw ..............................................................................377 Zarządzanie zdarzeniami ...................................................................................378 Skorowidz .....................................................................................................................................381 7 Architektura aplikacji po stronie serwera W tym rozdziale: (cid:81) 7.1. Projektowanie aplikacji dla wielu interfejsów (cid:81) 7.2. Wzorzec projektowy Model-Widok-Kontroler (cid:81) 7.3. Wykorzystanie wzorca Fabryka wraz z mechanizmem obsługi szablonów 240 244 269 239 240 Rozdział 7. Architektura aplikacji po stronie serwera P rojektowanie rozbudowanych aplikacji internetowych zazwyczaj koncen- truje się na programach działających po stronie klienta. Ma to sens, ponie- waż większość nowych technologii stosowanych w aplikacjach internetowych koncentruje się wokół obiektu JavaScript XMLHttpRequest. Jednak projektowa- nie aplikacji po stronie serwera w dalszym ciągu zasługuje na co najmniej tyle uwagi, ile wymagało ono przed upowszechnieniem się aplikacji sterowanych żądaniami Ajax. Technologie po stronie serwera nie tylko muszą w dalszym ciągu wspierać operacje ładowania kompletnych stron, ale także obsługiwać zapytania mające na celu aktualizację lub odczytywanie informacji w tle. Aplikacje tej natury wymagają dostatecznie elastycznej architektury, tak aby można było ograniczyć ładowanie danych i obiektów oraz wykonywanie ope- racji dla potrzeb obsługi bieżącego żądania. Zapewnienie tego samego poziomu kontroli autoryzacji i zestawu funkcji niezależnie od tego, jaka część aplikacji ładuje się dla określonego typu żądania, jest nie lada wyzwaniem. 7.1. Projektowanie aplikacji dla wielu interfejsów Aplikacje sterowane żądaniami Ajax wymagają dostępu do danych i zestawu funkcji przy użyciu co najmniej dwóch formatów odpowiedzi: XHTML i XML lub JSON. Spełnienie tego wymagania stwarza konieczność zapewnienia możliwości wypro- wadzania tych samych danych bądź wyników wywołań do dwóch różnych zesta- wów szablonów — to implikuje potrzebę elastycznego mechanizmu obsługi sza- blonów. Potrzebna jest również wystarczająco elastyczna architektura aplikacji — taka, która gwarantuje, że dla wybranego żądania nie będą wykonywane zbędne operacje. Aplikacja nie powinna zajmować się pobieraniem metadanych strony, struktur nawigacyjnych, czy też obsługą uprawnień związanych z dozwolonymi kontrol- kami interfejsu tylko po to, aby zwrócić prostą listę w odpowiedzi na wywołanie XMLHttpRequest. Potrzebna jest jednak pewna struktura tworząca kręgosłup aplikacji, a także mechanizm zapewniający załadowanie konfiguracji, nawiązanie połączenia z bazą danych, zarządzanie buforowaniem, przesyłaniem komunikatów, uwierzy- telnianiem, autoryzacją oraz ładowaniem zasobów. Dzięki należytej abstrakcji logiki w aplikacji można zapewnić łatwiejsze dyna- miczne ładowanie funkcji i ich wielokrotne wykorzystywanie w aplikacji. Dzięki temu łatwiejsza jest również praca z kodem aplikacji, ponieważ funkcje i metody mają znacznie bardziej zwięzłe definicje. Zaniedbania w odpowiedniej abstrakcji Projektowanie aplikacji dla wielu interfejsów 241 logiki aplikacji niezwykle utrudniają pielęgnację. W przypadku konieczności aktu- alizacji logiki powielonej w kilku miejscach aplikacji trzeba to robić wielokrotnie. Problemy są szczególnie dotkliwe, kiedy w powielonym kodzie znajduje się błąd, którego poprawienie ma istotne znaczenie — na przykład luka w zabezpieczeniach. Rozważmy funkcje biblioteczne języka PHP md5() i sha1(). Są to narzędzia do tworzenia skrótów (ang. hash) pozwalające na generowanie tokenów wykorzy- stywanych w plikach cookie, sesjach, operacjach weryfikacji źródeł przesyłania, nazwach plików oraz innych miejscach wymagających pozornie losowych, ale spójnych unikatowych identyfikatorów. Używa się ich zwłaszcza wtedy, gdy ist- nieje zagrożenie, że napastnikom uda się odgadnąć wspomniane identyfikatory i wykorzystać do realizacji różnych celów. Programiści zazwyczaj korzystają z tych funkcji bezpośrednio, ponieważ wywołanie sha1($text) zajmuje bardzo mało miejsca i nie pogarsza czytelności kodu. Może się jednak zdarzyć, że programista w wywołaniach funkcji nie poda argu- mentu salt1. W takim przypadku w kilku plikach źródłowych należy wprowadzić zmiany w sposób, który może nieco skomplikować kod — trzeba bowiem załado- wać parametry globalne i zarządzać ich wartościami. W niektórych zastosowaniach narzędzi generowania skrótów trzeba posługiwać się losową wartością argumentu salt, w innych argument ten jest prekonfigurowany — na przykład podczas gene- rowania skrótów haseł, aby zapewnić ich spójność. We wszystkich wynikających stąd scenariuszach w funkcjach należy uwzględnić więcej kodu, którego tam być nie powinno. class User extends DBO { /* ... */ public function set($field, $value) { if ($field == password ) { global $config; $salt = $config[ settings ][ salt ]; $hash = sha1($string . $salt); return parent::set($field, $hash); } else { return parent::set($field, $value); } } /* ... */ } 1 Więcej informacji na temat generowania skrótów z argumentem salt można znaleźć w rozdziale 8., „Bezpieczeństwo aplikacji internetowych”. 242 Rozdział 7. Architektura aplikacji po stronie serwera Powyższa definicja metody User::set() przeciąża bazową definicję DBO::set(). Ma to na celu ustawienie wartości pola password na skrót hasła zamiast jego war- tości tekstowej. Zaprezentowany sposób daje dostęp do globalnych ustawień kon- figuracyjnych umożliwiających skorzystanie z predefiniowanych wartości argu- mentu salt, ale obsługa tego argumentu i mechanizmu generowania skrótów wymaga miejsca wewnątrz metody User::set(). Praktyka ta nie ma sensu w poka- zanym kontekście i zaciemnia pierwotne przeznaczenie metody — zwłaszcza jeśli w jej obrębie zachodzi potrzeba implementacji dodatkowych funkcji w dalszej fazie projektowania. Oto kolejna wersja metody set: class User extends DBO { /* ... */ public function set($field, $value) { if ($field == password ) { return parent::set( $field, Utilities::hashWithSalt($value) ); } else { return parent::set($field, $value); } } /* ... */ } Powyższa definicja metody User::set() wymaga jedynie wywołania statycznej metody Utilities::hashWithSalt(), co sprawia, że jest ona znacznie łatwiejsza do pielęgnacji. W przypadku zmiany logiki związanej z generowaniem skrótów zmie- nić trzeba tylko definicje wewnątrz klasy Utilities. Dzięki temu, że jest tylko jedno miejsce wprowadzania zmian, zyskujemy pewność, że wymagana zmiana będzie wprowadzona we wszystkich fragmentach kodu, w których wykorzystano funkcje generowania skrótów. Oddzielenie logiki aplikacji od warstwy obsługi danych i prezentacji jest niezwy- kle pomocne w przypadku wszystkich aplikacji internetowych, a w szczególności w przypadku aplikacji internetowych sterowanych wywołaniami Ajaksa. Na przy- kład logika zaimplementowana w wielu miejscach aplikacji przyczynia się do powstania zależności prezentacji od metod przechowywania danych. Zdarza się również, że logika aplikacji, a nawet kod obsługi danych, stają się zależne od inter- fejsu prezentowanego użytkownikom. Zapisywanie kodu obsługi zapytań do baz danych i otrzymywanych wyników bezpośrednio w wyjściu XHTML prowadzi do powstania liniowego wyjścia o stru- Projektowanie aplikacji dla wielu interfejsów 243 kturze siatkowej (ang. grid-based) z bardzo ograniczonym zestawem funkcji. Ponie- waż kod niezbędny do zarządzania zapytaniami i zwracanymi wynikami już „skaził” kod związany z generowaniem zbioru znaczników strony, dodanie bar- dziej złożonych interfejsów jest znacznie trudniejsze do zaimplementowania, nie mówiąc już o pielęgnacji. W przypadku elementów interfejsu sterowanych żądaniami Ajax problem mie- szania interfejsu z logiką aplikacji wzrasta proporcjonalnie do liczby formatów wyniku, jakie powinna obsługiwać aplikacja — XML, JSON lub oba te formaty. Całą logikę, która powinna trafić do pierwotnej postaci kodu XHTML, należy teraz zdublować w każdej z metod wyniku obsługujących żądania Ajax. Jeśli w tym momencie, w związku z wywołaniami z poziomu kodu generującego każdy z for- matów wyjścia, zdarzy się sytuacja podobna do problemu logiki generowania skró- tów opisanego poprzednio, rozwiązanie problemu zajmie sporo czasu i wysiłku. Na przykład aplikacja może wyświetlać informacje użytkownika z wykorzysta- niem następującego kodu: div id= userinfo ?php $query = SELECT `id`, `login`, `nazwisko`, `email`, `utworzono` FROM `uzytkownicy` where `id` = . $id; if ($result = mysqli_query($query)) { if ($user = mysqli_fetch_assoc($result)) { // Wyświetlenie informacji o użytkowniku z wykorzystaniem tablicy asocjacyjne.j } else { // Użytkownika nie znaleziono. } } else { // Błąd zapytania. } ? /div W powyższym kodzie jest kilka problemów — wszystkie one mogłyby się poja- wić w kodzie odpowiedzi zarówno w formacie XML, jak i JSON. Na podstawie samego kodu programiści nie są w stanie stwierdzić, czy dla zmiennej $id zasto- sowano jakiekolwiek mechanizmy filtrowania bądź „unieszkodliwiania” znaków sterujących. Jeśli wystąpi błąd zapytania, programista ma jedynie możliwość obsłu- żenia i wyświetlenia komunikatu o błędzie w tym konkretnym punkcie wyniku. W tym momencie spora część wyniku mogła już dotrzeć do przeglądarki użyt- kownika. Kod generujący poprzedni wynik musi założyć powodzenie wykonania zapytania. Problem komplikuje następująca kwestia: co się stanie, jeśli aplikacja 244 Rozdział 7. Architektura aplikacji po stronie serwera musi obsłużyć inne mechanizmy obsługi baz danych? Zapytanie oraz kod bezpo- średnio komunikujący się z bazą danych nie może pozostać wewnątrz kodu ren- derowania wyniku, jeśli ma być zachowana jego łatwość pielęgnacji oraz uży- teczność. 7.2. Wzorzec projektowy Model-Widok-Kontroler Wzorzec projektowy MVC jest jednym z częściej używanych sposobów rozdzie- lania od siebie warstw logiki aplikacji, danych i prezentacji. Jak opisano w roz- dziale 3., „Architektura aplikacji po stronie klienta”, wzorzec ten oddziela logikę obsługi danych od logiki biznesowej oraz logiki prezentacji. Dzięki temu na przy- kład wiele części aplikacji może współdzielić jedną implementację logiki. Opisany wcześniej problem wstawianych w kodzie zapytań do bazy danych i logiki biznesowej nigdy nie może się zdarzyć w aplikacji korzystającej z modelu MVC, ponieważ warstwa prezentacji z samej definicji nie ma sposobu na to, by poznać metodę przechowywania danych, nie mówiąc już o użyciu zapytań i biblio- tek funkcji specyficznych dla tej metody przechowywania danych. Każdy z forma- tów wyniku, który należy zaimplementować w aplikacji (XHTML, XML, JSON, itd.), współdzieli tę samą logikę pobierania danych dzięki użyciu tych samych obiektów, a nie bezpośrednich wywołań. Jeśli zachodzi potrzeba modyfikacji dowolnego elementu tej logiki — na przykład jeśli aplikacja wymaga obsługi innego silnika bazy danych, można zmodyfikować odseparowaną logikę bez wpływu na kod pre- zentacji lub nawet logiki biznesowej. Ten sam problem dotyczy odseparowania funkcji generowania skrótów, opisanej we wcześniejszej części tego rozdziału. 7.2.1. Model Logika obsługi danych w aplikacji standardowo koncentruje się wokół interakcji z pamięcią masową aplikacji, zazwyczaj z bazą danych. W rzeczywistości jednak nie ma to wielkiego znaczenia, ponieważ sama logika obsługi danych jest nieza- leżna od typu pamięci masowej. Logika obsługi danych powinna dotyczyć tylko takich operacji, jak uprawnienia użytkowników, obsługa błędów oraz zależności. Aby to zapewnić, można wykorzystać mechanizm dziedziczenia w celu usunięcia metod obsługi pamięci masowej z logiki obsługi danych. Wzorzec projektowy Model-Widok-Kontroler 245 Podobnie jak każdy obiekt w większości języków obiektowych rozszerza klasę lub podklasę klasy Object2, wszystkie obiekty danych w aplikacji mogą rozszerzać klasę bazową DBO (opisującą obiekty obsługi bazy danych). Klasa ta zawiera cały kod niezbędny do tworzenia, odczytywania, aktualizowania i usuwania rekordów: /** * Klasa bazowa obiektów obsługi bazy danych. */ class DBO { // Klucze główne niektórych tabel mają inne nazwy. public $pk = id ; // Nazwa tabeli bazy danych. protected $table; // Nazwa tabeli bazy danych po „unieszkodliwieniu” znaków sterujących. private $table_mysql; // Tablica asocjacyjna pól tabeli do przechowywania ich wartości. protected $fields = array( id = null); // Tablica z kluczami $fields po poddaniu ich operacji „unieszkodliwiania” — tylko do // wewnętrznego użytku. private $fields_mysql; // Tablica opisująca ograniczenia dotyczące typu i rozmiaru poszczególnych pól. protected $fields_constraints = array(); // Tablica pól zaktualizowanych w określonym egzemplarzu. protected $updated = array(); // Flaga decydująca o tym, czy należy wywołać metodę insert() czy update() w momencie // wywołania metody save(). protected $inserted = false; /** * Jeśli pole istnieje, metoda zwraca jego bieżącą wartość, * w innym przypadku zwraca false. */ public function get($var) { if (array_key_exists($var, $this- fields)) { return $this- fields[$var]; } else { return null; } } /** * Jeśli pole istnieje, metoda aktualizuje wartość i oznacza jego miejsce w * zaktualizowanej tablicy, tak by skrypt aktualizacyjny miał informacje o polach, które ma * przetwarzać. 2 W języku PHP rolę klasy Object spełnia klasa stdClass. 246 Rozdział 7. Architektura aplikacji po stronie serwera */ public function set($field, $value) { if (array_key_exists($field, $this- fields)) { if ($this- fields[$field] != $value) { // Zgłoszenie wyjątku. if ($this- meetsFieldConstraints($field, $value)) { $this- fields[$field] = $value; $this- updated[$field] = true; } else { return false; } } return true; } else { return false; } } /** * Sprawdzenie ograniczeń pola w celu stwierdzenia, czy * podana wartość spełnia wymagania. Metoda zwraca * true, jeśli warunki ograniczeń są spełnione lub * zgłasza wyjątek w przeciwnym przypadku. */ protected function meetsFieldConstraints($field, $value) { // Jeśli nie zdefiniowano ograniczeń, to nie ma czego sprawdzać. if (isset($this- fields_constraints[$field])) { // Sprawdzenie typu. if (isset($this- fields_constraints[$field][ type ])) { Utilities::assertDataType( $this- fields_constraints[$field][ type ], $value ); } // Sprawdzenie rozmiaru. if (isset($this- fields_constraints[$field][ size ])) { Utilities::assertDataSize( $this- fields_constraints[$field][ size ], $value ); } } return true; } /** * Metoda pomocnicza umożliwiająca ustawienie wielu pól * na raz dzięki użyciu tablicy asocjacyjnej. Wzorzec projektowy Model-Widok-Kontroler 247 */ public function setAssoc($array) { if (is_array($array)) { foreach ($array as $field = $value) { $this- set($field, $value); } } else { return false; } } /** * Metoda save() sprawdza flagę inserted w celu podjęcia decyzji o tym, czy wstawiać * nowy rekord, czy też aktualizować istniejący. */ public function save() { if ($this- inserted) { return $this- update(); } else { return $this- insert(); } } /** * Usunięcie rekordu na podstawie jego klucza głównego. */ public function delete() { $statement = $this- database- prepare( DELETE FROM . $this- table_mysql . WHERE . $this- fields_mysql[$this- pk] . = ? ); if ($statement- execute(array($this- fields[$this- pk]))) { $this- inserted = false; return true; } else { return false; } } /** * Ustawienie zaktualizowanych pól rekordu na nowe wartości. */ protected function update() { if (!in_array(true, $this- updated)) { return true; } $qry = UPDATE . $this- table_mysql . SET ; $f = false; foreach ($this- updated as $field = $value) { 248 Rozdział 7. Architektura aplikacji po stronie serwera if (!$f) { $f = true; } else { $qry .= , ; } $qry .= $this- fields_mysql[$field] . = ? ; } $qry .= WHERE . $this- fields_mysql[$this- pk] . = ? ; $statement = $this- database- prepare($qry); // Pobiera zaktualizowane wartości pól i dodaje klucz główny // dla klauzuli WHERE. $parameters = array_push( array_intersect_key($this- fields, $this- updated), $this- fields[$this- pk] ); if ($statement- execute($parameters)) { return true; } else { return false; } } /** * Wprowadzenie bieżących wartości do nowego rekordu bazy danych. */ public function insert() { $qry = INSERT INTO . $this- table_mysql . ( . implode( , , $this- fields_mysql) . ) VALUES ( . str_repeat( ?, , count($this- fields) - 1) . ?) ; $statement = $this- database- prepare($qry); if ($statement- execute($this- fields)) { $this- inserted = true; $this- fields[$this- pk] = mysql_insert_id(); return true; } else { $GLOBALS[ messenger ]- addError( $this- database- errorInfo() ); return false; } } /** * Alias metody DBO::select($pk, $id); */ public function load($id) { $fields = array($this- pk); Wzorzec projektowy Model-Widok-Kontroler 249 $values = array($id); return $this- select($fields, $values); } /** * Wybór rekordu na podstawie tablicy pól w celu porównania * z tablicą wartości. */ public function select($fields, $values) { global $config; if (is_array($fields) is_array($values)) { $qry = SELECT ( . implode( , , $this- fields_mysql) . ) FROM . $this- table_mysql . WHERE ; $f = false; foreach ($fields as $i = $field) { if (isset($this- fields_mysql[$field])) { if (!$f) { $f = true; } else { $qry .= AND ; } $qry .= $this- fields_mysql[$field] . = ? ; } } $statement = $this- database- prepare($qry); if ($statement- execute($values)) { if ($row = $statement- fetch(PDO::FETCH_ASSOC)) { $this- fields = $row; $this- inserted = true; return true; } } else { $error = $statement- errorInfo(); $GLOBALS[ messenger ]- add($error[2], error ); } } return false; } /** * Ponieważ rozszerzenie PDO nie „unieszkodliwia” identyfikatorów tabeli i pól, * ta metoda tworzy prywatną, „nieszkodliwą” i ujętą w cudzysłów kopię * identyfikatorów tabeli i pól do wykorzystania w zapytaniach SQL. */ protected function escapeIdentifiers() { $this- table_mysql = $this- escapeTable($this- table); foreach ($this- fields as $field = $value) { $this- fields_mysql[$field] = $this- escapeIdentifier($field); 250 Rozdział 7. Architektura aplikacji po stronie serwera } } /** * Nazwy tabel podlegają różnym ograniczeniom. * Dodatkowo w bazie danych MySQL nazwy tabel nie mogą kończyć się spacją ani * zawierać znaków / , lub . */ protected function escapeTable($string) { // Nazwy tabel w systemie MySQL podlegają nieco innym // ograniczeniom. $temp = preg_replace( /[/\.]/D , , $string); $temp = str_replace( ` , `` , $temp); return ` . trim($temp) . ` ; } /** * W nazwach pól należy „unieszkodliwić” wszystkie lewe apostrofy (ang. backtick). */ protected function escapeIdentifier($string) { return ` . str_replace( ` , `` , $string) . ` ; } /** * Kiedy obiekt wywołujący podaje identyfikator ID, należy wywołać metodę DBO::load() * w celu załadowania rekordu. */ public function __construct($id = null) { global $controller; $this- database = $controller- getDatabaseHandle(); if (!is_null($id)) { $this- load($id); } $this- escapeIdentifiers(); } } Zaprezentowana klasa DBO implementuje wszystkie podstawowe metody nie- zbędne do zarządzania odpowiednikami rekordów bazy danych w postaci obiek- tów danych w PHP. Klasa zamyka w sobie bezpośrednie operacje z bazą danych potrzebne do zarządzania indywidualnymi rekordami. Dzięki wykorzystaniu roz- szerzenia PDO ich pisanie jest znacznie łatwiejsze, zwłaszcza kiedy aplikacja wymaga zapewnienia przenośności do innych systemów baz danych. Dla zapy- tań również należałoby zapewnić mechanizm obsługi konkretnych baz danych. Przenośność aplikacji do innych systemów baz danych bez wielkiego wpływu na Wzorzec projektowy Model-Widok-Kontroler 251 architekturę aplikacji oraz logikę w warstwie modelu implementacji wzorca MVC można zapewnić dzięki wykorzystaniu biblioteki generowania zapytań, biblioteki zapisanych wstępnie zapytań lub dowolnej innej metody abstrakcji kodu SQL. Zazwyczaj cała warstwa obsługi bazy danych jest umieszczona pomiędzy obiek- tami danych a operacjami z bazą danych — w klasach dostępu do danych. Modyfika- cje schematu, obsługa dodatkowych silników baz danych, a nawet przechowywanie danych poza bazami danych są dzięki temu o wiele łatwiejsze. W niniejszej książce nie opisano tego zagadnienia, głównie dlatego, aby na architekturze strony serwerowej aplikacji sterowanych wywołaniami Ajaksa skoncentrować się w tym rozdziale. Dzięki rozszerzeniom tego obiektu fragmenty warstwy modelu w aplikacji mogą zawierać dokładnie tyle logiki, ile potrzeba bez konieczności zaśmiecania kodu źró- dłowego kodem obsługi pamięci masowej. Dzięki temu można implementować dodatkowe własności, takie jak zamieszczona poniżej klasa Session będąca rozsze- rzeniem klasy DBO. Jej celem jest umożliwienie dostępu do danych sesji za pośred- nictwem tego samego ogólnego interfejsu przy jednoczesnym zapewnieniu zarzą- dzania rekordem sesji w bazie danych: // W aplikacji należy włączyć ten plik tylko raz // i rozpocząć sesję tylko raz. session_start(); /** * Klasa Session zarządza danymi w tabeli user_sessions , * przy czym jej podstawowym przeznaczeniem jest zarządzanie sesją PHP. * Strukturę tę można by równie dobrze wykorzystać do zapisania wszystkich danych sesji * w tabeli bazy danych, zamiast używania wbudowanych mechanizmów obsługi sesji języka PHP, * bez konieczności zmian w interfejsie obiektowym. */ class Session extends DBO { public $pk = session ; // Odwołanie do zmiennej superglobalnej $_SESSION. protected $session; // Tabela łącząca dane użytkowników z tablicą $_SESSION. protected $table = user_sessions ; protected $fields = array( user = null, session = null ); 252 Rozdział 7. Architektura aplikacji po stronie serwera /** * Odtworzenie identyfikatorów sesji poprawia bezpieczeństwo, zwłaszcza w przypadku * wywołania po pomyślnym zalogowaniu z wykorzystaniem danych identyfikacyjnych. */ public function regenerate() { session_regenerate_id(true); $this- fields[$this- pk] = session_id(); return $this- save(); } /** * Metoda Session::get() przeciąża metodę DBO::get() w celu * obsługi przezroczystego pobierania informacji * z sesji. */ public function get($key) { if ($key == id ) { return session_id(); } else if ($key == user ) { return $this- fields[ user ]; } else if (isset($this- session[$key])) { return $this- session[$key]; } else { return false; } } /** * Metoda Session::set() przeciąża metodę DBO::set() w celu * obsługi przezroczystego ustawiania informacji * dotyczących sesji. */ public function set($key, $value) { if ($key == id ) { return false; } else if ($key == user ) { $this- fields[ user ] = $value; } else { $this- session[$key] = $value; } return true; } /** * Ponieważ wartość klucza głównego pochodzi z żądania * (za pośrednictwem sesji w przeglądarce), metoda Session::load * powinna umożliwiać automatyczną obsługę przekazywanych danych. */ Wzorzec projektowy Model-Widok-Kontroler 253 public function load() { return parent::load($this- fields[$this- pk]); } /** * Przeciążenie konstruktora w celu utworzenia referencji do * zmiennej superglobalnej $_SESSION. */ public function __construct() { global $_SESSION; parent::__construct(); $this- session = $_SESSION; } } Klasa Session ma stosunkowo prostą implementację, ponieważ jej nadrzędna klasa DBO implementuje wszystko, co jest potrzebne do zarządzania odpowiada- jącym jej rekordem bazy danych. Ponieważ egzemplarze klasy Session również mogą mieć prosty interfejs obiektowy, uwierzytelnianie użytkownika na podstawie jego sesji i ładowanie danych tego użytkownika do obiektu User można wykonać za pomocą poniższego prostego kodu umieszczonego wewnątrz metody klasy User: if ($this- session- load()) { if ($userid = $this- session- get( user )) { if ($this- load($userid)) { //Uwierzytelniony użytkownik z prawidłową sesją. } else { // Nieprawidłowy lub przeterminowany rekord sesji zwracający niepoprawny // identyfikator użytkownika. } } else { // Użytkownik z anonimową sesją. } } else { // Użytkownik z całkowicie nową sesją. } Ściślejsza kontrola błędów, rejestrowanie i informowanie użytkownika o wyko- nywanych operacjach poprawiłyby „elegancję” tego kodu, trzeba jednak podkre- ślić, że w tym przykładzie logika interakcji z egzemplarzem klasy Session, mająca na celu określenie jej stanu z dokładnością do czterech stopni szczegółowości, zajęła tylko pierwsze dwa wiersze. Dane sesji można by zapisać z wykorzystaniem wbu- dowanych metod obsługi sesji języka PHP, niestandardowej tabeli bazy danych, 254 Rozdział 7. Architektura aplikacji po stronie serwera tymczasowych plików XML lub po prostu w pamięci. Metody obsługi danych nie mają wpływu na interfejs obiektowy dostępu do danych, a dzięki abstrakcji opera- cje zapisu i odczytu danych, niezależnie od ich docelowej lokalizacji, są trywialne. 7.2.2. Kontroler Kontroler w architekturze MVC zawiera całą logikę aplikacji. W jego obrębie jest cały kod dotyczący interakcji z obiektami. Kontroler obsługuje również potrzebne operacje oraz wszystkie inne działania wymagane przez aplikacje, które nie miesz- czą się w zakresie zarządzania danymi oraz logiki prezentacji. Do jego zadań należą testy autoryzacyjne związane z operacjami (za te, które dotyczą danych, jest odpo- wiedzialna warstwa modelu), ładowanie zasobów oraz cała logika biznesowa zwią- zana z operacjami. Kontroler ładuje również zasoby wymagane przez warstwę Widok oraz przekazuje dane i zasoby potrzebne do renderowania strony. 7.2.2.1. Zagnieżdżone kontrolery W celu zapobieżenia konieczności kodowania tego samego kodu architektury w każdym obiekcie kontrolera aplikacja może zawierać obiekt centralnego kon- trolera, którego zadaniem jest wykonywanie tych wspólnych zadań. Każdy kon- troler zagnieżdżony wewnątrz centralnego kontrolera skupia się tylko na tej logice, która go dotyczy. Dzięki temu znacznie łatwiejsze jest również wprowadzanie modyfikacji w architekturze, w przypadku kiedy zachodzi taka potrzeba na dal- szych etapach projektowania. Centralny kontroler w przykładzie zamieszczonym poniżej jest maksymalnie ograniczony i spełnia jedynie rolę solidnej osi dla aplikacji. Jego zadaniem jest zainicjowanie obsługi żądania, utworzenie połączenia z bazą danych oraz skon- figurowanie środowiska dla pozostałej części aplikacji. W dalszej kolejności cen- tralny kontroler wyznacza kontroler wymagany dla wybranego żądania, ładuje go i przekazuje do niego żądania w celu wykonania kodu związanego z wybranym fragmentem zestawu funkcji aplikacji. Struktura ta w maksymalnym stopniu oddziela logikę związaną z samą archi- tekturą od właściwej logiki aplikacji, dzięki czemu kod staje się bardziej czytelny i łatwiejszy do pielęgnacji. W ten sposób aplikacja może załadować poszczególne funkcje w miarę potrzeb zamiast ładowania dużych fragmentów kodu dla każ- dego żądania. Wzorzec projektowy Model-Widok-Kontroler 255 Zaprezentowana poniżej klasa CentralController nie obsługuje logiki potrzeb- nej do zarządzania żądaniami w większym stopniu niż jest to konieczne do załado- wania właściwego kontrolera dla tego obszaru funkcji aplikacji. Dzięki zagnież- dżaniu kontrolerów w ten sposób logika szkieletu aplikacji może pozostać we własnej, centralnej klasie, natomiast każdy z kontrolerów podrzędnych obsługuje swoją własną logikę. Dzięki tej dodatkowej warstwie abstrakcji klasy są znacznie bardziej czytelne. Poza tym (oraz dzięki prostej klasie Utilities lub dostępnej globalnie bibliotece funkcji) każda klasa zawiera tylko tyle kodu, ile jest niezbędne do spełnienia swojej roli. class CentralController { // Alias tablicy konfiguracyjnej. protected $config; // Odwołania do zmiennych globalnych. protected $raw_get; protected $raw_post; protected $raw_request; protected $raw_headers; // Kontroler dla wybranego fragmentu. protected $controller; // Odwołanie do bieżącego użytkownika. protected $user; public function handleRequest($get, $post = null, $request = null) { $this- raw_get = $get; $this- raw_post = (is_null($post)) ? array() : $post; $this- raw_request = (is_null($request)) ? array() : $request; try { $this- loadUser(); $this- loadController(); $this- passTheBuck(); } catch (Exception $e) { // Strona z komunikatem o błędzie krytycznym. } } protected function loadUser() { try { Utilities::loadModel( User ); $this- user = new User(); $this- user- authenticate(); } catch (Exception $e) { exit($e- getMessage()); } } 256 Rozdział 7. Architektura aplikacji po stronie serwera protected function loadController() { global $controllers; // Jeśli nie określono kontrolera, wykorzystanie kontrolera domyślnego. $controller_key = default ; if (isset($this- raw_get[ c ]) isset($controllers[$this- raw_get[ c ]])) { $controller_key = $this- raw_get[ c ]; } // Wyszukanie kontrolera lub zgłoszenie wyjątku. $controller_path = controllers/ . $controllers[$controller_key][ filename ] . / . $controllers[$controller_key][ filename ] . .php ; // Sprawdzenie, czy plik istnieje przed jego załadowaniem na wypadek, gdyby jego lokalizacja // zmieniła się od chwili generowania listy dostępnych kontrolerów. if (!file_exists($controller_path)) { throw new Exception( Kontrolera nie znaleziono ); } // Załadowanie pliku i utworzenie egzemplarza obiektu kontrolera. include $controller_path; $this- controller = new $controllers[$controller_key][ class ](); return true; } /** * Prosta metoda do ładowania nagłówków żądania HTTP. * Zwraca żądaną wartość, jeśli ona istnieje. */ public function getHeader($key) { // Późne ładowanie nagłówków apache. if (!isset($this- raw_headers)) { $this- raw_headers = apache_request_headers(); } if (isset($this- raw_headers[$key])) { return $this- raw_headers[$key]; } else { return false; } } protected function passTheBuck() { $this- controller- handleRequest( $this- raw_get, $this- raw_post, $this- raw_request ); } public function getDatabaseHandle() { Wzorzec projektowy Model-Widok-Kontroler 257 if (!isset($this- database)) { $this- loadDatabase(); } return $this- database; } protected function loadDatabase() { $this- database = new PDO( $this- config[ database ][ dsn ], $this- config[ database ][ username ], $this- config[ database ][ password ], $this- config[ database ][ options ] ); } public function display() { $this- controller- display(); } public function __construct() { include configuration.php ; $this- config = $config; } } Ten kontroler może również rozwiązywać problem dostarczania co najmniej jednego tokenu dla każdego zagnieżdżonego kontrolera. Powinien on być unika- towy dla sesji użytkownika i zakodowany z wykorzystaniem losowego ciągu z klasy Utilities. Praktyka ta pozwala na to, aby zagnieżdżone kontrolery sprawdzały obecność tokenu walidacyjnego właściwego dla operacji, dla której należy zapew- nić autoryzację. W rezultacie napastnikom jest o wiele trudniej przeprowadzić atak CSRF. Logika danego fragmentu aplikacji jest oddzielona od logiki pozostałych frag- mentów dzięki wykorzystaniu implementacji obiektu CentralController, przy czym każdy fragment uzyskuje dodatkową warstwę zabezpieczeń. Zamieszczone poniżej zmienne i metody dodane do obiektu CentralController umożliwiają sprawdzanie tokenu walidacyjnego za pośrednictwem wymaganego sposobu (zmiennej POST lub nagłówka HTTP) poprzez wywołanie pojedynczej metody obiektu CentralCon (cid:180)troller: // Flaga typu Boolean wskazująca na to, czy token walidacyjny jest prawidłowy. protected $validated = false; protected $validation_token; 258 Rozdział 7. Architektura aplikacji po stronie serwera /** * Pobranie tokenu właściwego dla bieżącego obszaru aplikacji, * ale tylko wtedy, gdy użytkownik przeszedł z innego obszaru. */ protected function generateValidationToken($area) { // Pobranie ostatnio przeglądanego obszaru zapisanego w sesji. $last_viewed = $this- user- session- get( last_viewed_area ); // Ponowne wygenerowanie tokenu i zastosowanie go dla sesji, // w przypadku, gdy jest to obszar różny od bieżącego. if ($area != $last_viewed) { $session = $this- user- session- get( id ); $this- validation_token = Utilities::generateToken($area . $session); $this- user- session- set( last_viewed_area , $area); } } /** * Walidacja tokenu z nagłówkami żądania. */ public function validateHeader() { return $this- validateToken( $this- getHeader( $this- config[ settings ][ validation ] ) ); } /** * Walidacja tokenu z danymi POST. */ public function validatePost() { if (isset($this- raw_post[$this- config[ settings ][ validation ]])) { return $this- validateToken( $this- raw_post[$this- config[ settings ][ validation ]] ); } } /** * Sprawdzenie, czy bieżący token oraz token żądania są ze sobą zgodne. */ public function validateToken($test) { return ($test === $this- validation_token); } Teraz obiekt CentralController na podstawie bieżącego żądania musi jedynie wywołać metodę w celu wygenerowania tokenu do wykorzystania w metodach walidacyjnych. Ponieważ w związku z tym token będzie zależny od kontrolera, Wzorzec projektowy Model-Widok-Kontroler 259 dobrym rozwiązaniem będzie wykorzystanie klucza dla kontrolera w tablicy asocja- cyjnej skonfigurowanej wcześniej. Metoda loadController() może następnie wywo- łać metodę generowania tokenu po tym, gdy pomyślnie utworzy egzemplarz kon- trolera z wykorzystaniem tego samego klucza: protected function loadController() { global $controllers; // Jeśli nie określono kontrolera, wykorzystanie kontrolera domyślnego. $controller_key = default ; if (isset($this- raw_get[ c ]) isset($controllers[$this- raw_get[ c ]])) { $controller_key = $this- raw_get[ c ]; } // Wyszukanie kontrolera lub zgłoszenie wyjątku. $controller_path = controllers/ . $controllers[$controller_key][ filename ] . / . $controllers[$controller_key][ filename ] . .php ; // Sprawdzenie, czy plik istnieje przed jego załadowaniem na wypadek, gdyby lokalizacja // zmieniła się od chwili generowania listy dostępnych kontrolerów. if (!file_exists($controller_path)) { throw new Exception( Kontrolera nie znaleziono ); } // Wygenerowanie tokenu walidacji żądania. $this- generateValidationToken($controller_key); // Załadowanie pliku i utworzenie egzemplarza obiektu kontrolera. include $controller_path; $this- controller = new $controllers[$controller_key][ class ](); return true; } Teraz, kiedy obiekt CentralController potrafi obsłużyć wstępne żądanie, zaini- cjować połączenie z bazą danych, podjąć próbę załadowania i uwierzytelniania użytkownika, załadować w dynamiczny sposób kontroler ze zbioru zagnieżdżo- nych kontrolerów oraz zapewnić dostępną globalnie prostą ochronę przed atakami CSRF, zagnieżdżone kontrolery mogą działać na bazie tej warstwy zgodnie z wła- snymi wymaganiami. Zagnieżdżony kontroler, zamieszczony poniżej, wykonuje tylko jedną opera- cję: połączenie formularza rejestracyjnego użytkownika z obiektem User w celu utworzenia rekordu w bazie danych po tym, gdy użytkownik wprowadzi wszyst- kie potrzebne informacje. Wszystkie elementy z warstwy bazy danych są oddzielone od widoku, kontroler jedynie zaopatruje widok w dane i obsługuje jego odpowiedzi. 260 Rozdział 7. Architektura aplikacji po stronie serwera Umieszczenie niektórych fragmentów kodu bazowego, niespecyficznych dla pro- cesu rejestracji, miałoby więcej sensu w nadrzędnej klasie Controller, którą poniższy kontroler mógłby rozszerzać. Jednak dla zapewnienia przejrzystości opisu w tym rozdziale kontroler ten zdefiniowano w postaci pojedynczej klasy: Utilities::loadModel( User ); class RegistrationController { // Odwołania do zmiennych globalnych. protected $raw_get; protected $raw_post; protected $raw_request; // Utworzenie odwołania do obiektu użytkownika. protected $user; protected $userinfo = array( login = null, name = null, email = null, password = null ); // Obiekt obsługujący wyjście. protected $view; // Sposób odpowiedzi na żądanie. protected $method; /** * Pobranie metody żądania z widoku, utworzenie egzemplarza silnika * renderowania, ustawienie kontekstu renderowania do katalogu, w którym znajduje się ten plik, * odfiltrowanie żądania i podjęcie próby utworzenia rekordu użytkownika na podstawie * danych żądania. */ public function handleRequest($get, $post = null, $request = null) { // Utworzenie silnika renderowania. $this- method = View::getMethodFromRequest($get); $this- view = View::getRenderingEngine($this- method); $this- view- setContext(dirname(__FILE__)); // Zastosowanie filtra dla żądania. $this- filterRequest($get, $post, $request); // próba utworzenia nowego rekordu użytkownika z wykorzystaniem filtrowanego żądania. $this- createUser(); } /** * Akceptacja danych żądania tylko wtedy, gdy obiekt CentralController dokona walidacji * wartości nagłówka lub zmiennej post w przypadku operacji ładowania pełnej strony (przesłanie * formularza). */ Wzorzec projektowy Model-Widok-Kontroler 261 public function filterRequest($get, $post = null, $request = null) { global $controller; if ($controller- validateHeader() || ($this- method == View::METHOD_XHTML $controller- validatePost())) { $this- raw_get = $get; $this- raw_post = (is_null($post)) ? array() : $post; $this- raw_request = (is_null($request)) ? array() : $request; } else { return false; } } /** * Próba utworzenia rekordu użytkownika w przypadku, gdy istnieją wszystkie pola. * Przekazanie komunikatów o błędach do obiektu Messenger. */ protected function createUser() { global $messenger; $this- user = new User(); if ($this- getUserInfo()) { $errors_found = false; foreach ($this- userinfo as $field = $value) { try { $this- user- set($field, $value); } catch (Exception $e) { if (!$errors_found) { $errors_found = true; } $messenger- add($e- getMessage(), $field); } } if (!$errors_found) { try { $this- user- save(); } catch (Exception $e) { $messenger- add($e- getMessage(), error ); } } } } /** * Pobranie wartości pól wszystkich użytkowników z żądania post * pod warunkiem, że hasło i jego potwierdzenie * są ze sobą zgodne. */ 262 Rozdział 7. Architektura aplikacji po stronie serwera public function getUserInfo() { global $messenger; foreach ($this- userinfo as $field = $value) { if (isset($this- raw_post[$field])) { if ($field == login User::loginExists($value)) { $messenger- add( Nazwa użytkownika jest zajęta , login ); continue; } else if ($field == password ) { if (!isset($this- raw_post[ password_confirm ]) || $this- raw_post[$field] != $this- raw_post[ password_confirm ]) { $messenger- add( Hasło i jego potwierdzenie muszą być ze sobą zgodne , password ); continue; } } $this- userinfo[$field] = $this- raw_post[$field]; } } return in_array(null, $this- userinfo); } /** * Wyświetlenie wyjścia mechanizmu renderowania z wykorzystaniem * odpowiedniego szablonu dla wybranego formatu żądania. */ public function display() { switch ($this- method) { case View::METHOD_JSON: $this- view- setTemplate( json.php ); break; case View::METHOD_XML: $this- view- setTemplate( xml.php ); break; case View::METHOD_XHTML: default: $this- view- setTemplate( index.php ); break; } $this- view- display(); } } Pokazany powyżej obiekt RegistrationController obsługuje logikę rejestracji użytkownika zgodnie z wcześniejszym opisem. Próba utworzenia rekordu użytkow- nika jest wykonywana tylko wtedy, gdy w formularzu wprowadzono wszystkie Wzorzec projektowy Model-Widok-Kontroler 263 niezbędne pola. Obiekt sprawdza, czy podana nazwa użytkownika nie jest zajęta, i przekazuje informacje o błędach do obiektu Messenger. Błędy są podzielone na kategorie odpowiadające polom, których dotyczy dany błąd (lub są zaliczone do ogólnej kategorii błędów metody User::save()). Dzięki temu warstwa widoku może odpowiednio obsłużyć wszystkie komunikaty i błędy. Własność tę można również zaimplementować w postaci ogólnej warstwy usług. Dzięki temu bez konieczności przepisywania kodu inne obiekty mogą wykonać te same testy. T
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Ajax dla zaawansowanych. Architektura i najlepsze rozwiązania
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: