Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00371 007511 13457706 na godz. na dobę w sumie
Rails. Sztuka programowania - książka
Rails. Sztuka programowania - książka
Autor: Liczba stron: 336
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2071-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> rails - programowanie
Porównaj ceny (książka, ebook, audiobook).

Ruby on Rails przebojem wdarł się na rynek szkieletów aplikacji internetowych. Stworzony w architekturze MVC z wykorzystaniem popularnego języka Ruby, został entuzjastycznie przyjęty przez społeczność programistów. Główne założenia tego projektu to łatwość i przyjemność tworzenia kodu, a co za tym idzie -- szybkie i efektywne tworzenie aplikacji internetowych. Liczba rozwiązań, które powstały z wykorzystaniem tego szkieletu, świadczy o jego wysokiej jakości oraz znacząco wpływa na wzrost popularności samego języka Ruby.

Jeżeli ta książka znalazła się w Twoich rękach, to z pewnością powyższe wiadomości nie są Ci obce. Kierowana jest ona do programistów, którzy znają już Ruby on Rails i pragną pogłębić swoją wiedzę. Dzięki książce 'Rails. Sztuka programowania' dowiesz się, jak organizować swój kod tak, aby osiągnąć najwyższą efektywność i zachować zgodność z ideą DRY (Don't Repeat Yourself). Poznasz zasady zaawansowanego programowania w języku Ruby wraz z metaprogramowaniem oraz nauczysz się korzystać z programowania opartego na blokach. Ponadto zapoznasz się z wzorcami projektowymi dla technologii AJAX, interfejsami programistycznymi dla WWW, dekompozycją kodu HTML oraz nauczysz się w wydajny sposób rozwijać schemat bazy danych. Z pewnością zainteresuje Cię rozdział poświęcony programowaniu sterowanym zachowaniem. Te i wiele innych informacji znajdziesz w niniejszej książce, która wydaje się być obowiązkową dla każdego programisty Ruby on Rails!

Opanuj sztukę programowania w Ruby on Rails!

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

Darmowy fragment publikacji:

Rails. Sztuka programowania Autor: Edward Benson T³umaczenie: Rafa³ Joñca ISBN: 978-83-246-2071-5 Tytu³ orygina³u: The Art of Rails Format: 172x245, stron: 336 Oprawa: twarda • Jak osi¹gn¹æ najwiêksze korzyœci z architektury MVC? • Jak programowaæ, korzystaj¹c z bloków? • Jak tworzyæ Web API? Ruby on Rails przebojem wdar³ siê na rynek szkieletów aplikacji internetowych. Stworzony w architekturze MVC z wykorzystaniem popularnego jêzyka Ruby, zosta³ entuzjastycznie przyjêty przez spo³ecznoœæ programistów. G³ówne za³o¿enia tego projektu to ³atwoœæ i przyjemnoœæ tworzenia kodu, a co za tym idzie — szybkie i efektywne tworzenie aplikacji internetowych. Liczba rozwi¹zañ, które powsta³y z wykorzystaniem tego szkieletu, œwiadczy o jego wysokiej jakoœci oraz znacz¹co wp³ywa na wzrost popularnoœci samego jêzyka Ruby. Je¿eli ta ksi¹¿ka znalaz³a siê w Twoich rêkach, to z pewnoœci¹ powy¿sze wiadomoœci nie s¹ Ci obce. Kierowana jest ona do programistów, którzy znaj¹ ju¿ Ruby on Rails i pragn¹ pog³êbiæ swoj¹ wiedzê. Dziêki ksi¹¿ce „Rails. Sztuka programowania” dowiesz siê, jak organizowaæ swój kod tak, aby osi¹gn¹æ najwy¿sz¹ efektywnoœæ i zachowaæ zgodnoœæ z ide¹ DRY (Don’t Repeat Yourself). Poznasz zasady zaawansowanego programowania w jêzyku Ruby wraz z metaprogramowaniem oraz nauczysz siê korzystaæ z programowania opartego na blokach. Ponadto zapoznasz siê z wzorcami projektowymi dla technologii AJAX, interfejsami programistycznymi dla WWW, dekompozycj¹ kodu HTML oraz nauczysz siê w wydajny sposób rozwijaæ schemat bazy danych. Z pewnoœci¹ zainteresuje Ciê rozdzia³ poœwiêcony programowaniu sterowanym zachowaniem. Te i wiele innych informacji znajdziesz w niniejszej ksi¹¿ce, która wydaje siê byæ obowi¹zkow¹ dla ka¿dego programisty Ruby on Rails! • Ca³a prawda o aplikacjach internetowych • Koncepcja Rails • Architektura MVC • Zarz¹dzanie cyklem ¿ycia aplikacji • Korzyœci z zastosowania architektury MVC • Zastosowanie technologii ActiveRecord • Tworzenie Web API • Wykorzystanie zasobów oraz obs³uga ¿¹dañ REST • Zastosowanie formatów XML, RSS, RDF • Sposoby ograniczania dostêpu do API • Wzorce zastosowañ technologii AJAX • Zasady programowania z wykorzystaniem bloków • Mieszanie i ³atanie klas • Wykorzystanie dynamicznego kodu • RSpec — programowanie sterowane zachowaniem • Cykl programowania Opanuj sztukê programowania w Ruby on Rails! Spis treÊci 5 Spis treÊci O autorze ...................................................................................................................................................11 PodziÂkowania .........................................................................................................................................13 Wprowadzenie .........................................................................................................................................15 RozdziaÄ 1. Rozwój nowego systemu witryn internetowych .................................................................21 Rails, sztuka i nowy internet .......................................................................................... 23 Sztuka i inĔynieria ................................................................................................... 23 Nowe witryny WWW ................................................................................................. 24 Prawda o aplikacjach internetowych .......................................................................... 25 Historia pacjenta — witryny internetowe ......................................................................... 26 Od dokumentów do interfejsów ................................................................................ 29 Upadek semantyki .................................................................................................. 30 Witajcie, aplikacje internetowe ................................................................................. 33 Pojawienie siö nowego podejĈcia ................................................................................... 40 RozdziaÄ 2. Koncepcja Rails .....................................................................................................................41 W jednej czöĈci szkielet ................................................................................................ 43 Konfiguracja ........................................................................................................... 43 Kod ....................................................................................................................... 45 Proces ................................................................................................................... 46 W jednej czöĈci jözyk .................................................................................................... 48 Modele w Rails ....................................................................................................... 49 Zadania specyficzne dla stron WWW ......................................................................... 51 JavaScript .............................................................................................................. 52 Moduäy dodatkowe .................................................................................................. 53 W dwóch czöĈciach sposób myĈlenia ............................................................................. 53 Witryny internetowe to aplikacje MVC ........................................................................ 54 Aplikacje internetowe to ekosystemy ........................................................................ 54 Konwencja ponad konfiguracjö ................................................................................. 55 Maäe zaäoĔenie przebywa däugñ drogö ....................................................................... 56 Kwestie estetyczne ................................................................................................. 57 6 Rails. Sztuka programowania Wyzwalajñce ograniczenia ........................................................................................ 58 Zbyt mocno siö powtarzasz ...................................................................................... 60 Testowanie nie jest opcjonalne ................................................................................ 62 Sieè to zbiór zasobów, a nie usäug ............................................................................ 63 Podsumowanie ............................................................................................................ 64 Zäoty Ĉrodek nie istnieje .......................................................................................... 65 Optymizuj swój sposób kodowania, zanim przystñpisz do optymalizacji kodu ................ 65 RozdziaÄ 3. Serwer jako aplikacja .........................................................................................................67 Model-widok-kontroler w wersji skróconej ....................................................................... 69 MVC i strony WWW ....................................................................................................... 71 Proces projektowy MVC ................................................................................................. 72 Widok to specyfikacja .............................................................................................. 73 Przykäad — portal spoäecznoĈciowy dla kucharzy ........................................................ 74 Zarzñdzanie cyklem Ĕycia aplikacji ................................................................................. 78 MyĈl w sposób lekki, nie inĔynieryjny ........................................................................ 78 MyĈl w sposób kontrolowany, a nie organiczny .......................................................... 79 StrzeĔ siö operacji na otwartym sercu ....................................................................... 79 Podsumowanie ............................................................................................................ 80 RozdziaÄ 4. Osi¾gniÂcie jak najwiÂkszych korzyÊci z M, V i C ..............................................................81 Najlepsza dokumentacja interfejsów jest gratis ............................................................... 82 Model ......................................................................................................................... 83 Obiekty modeli powinny siö nawzajem rozumieè ......................................................... 84 UĔyj wyjñtków, by zwiökszyè czytelnoĈè kodu ............................................................. 86 Odwzorowanie z wierszy na obiekty ........................................................................... 89 Asocjacje polimorficzne ........................................................................................... 90 ćwiat poza ActiveRecord .......................................................................................... 92 Widok .......................................................................................................................... 92 Problem zmiennej ................................................................................................... 93 JavaScript w stylu Rails ........................................................................................... 94 Fragmenty jako atomy i molekuäy .............................................................................. 95 Wybór odpowiednich fragmentów .............................................................................. 97 Widok to nie tylko HTML .......................................................................................... 99 Kontroler ................................................................................................................... 100 CRUD do wielokrotnego zastosowania .................................................................... 101 Rusztowanie w Rails to zbiór operacji CRUD ............................................................ 102 Obsäuga akcji dwukrokowych .................................................................................. 103 Kiedy przekazaè prace na zewnñtrz ......................................................................... 106 Kiedy refaktoryzowaè ............................................................................................. 110 Podsumowanie .......................................................................................................... 111 RozdziaÄ 5. PiÂkne interfejsy aplikacji ...................................................................................................113 Dwa wielkie pomysäy na Web API ................................................................................. 115 Nowy adres URL — adresacja zagadnieþ, nie plików ................................................ 115 Aplikacja to interfejs .............................................................................................. 117 Odwzorowania adresów ............................................................................................... 118 Anatomia wywoäania Web API ...................................................................................... 121 Nakäadanie API ........................................................................................................... 121 Metoda respond_to ............................................................................................... 122 Zapis wyniku w formacie innym niĔ HTML ................................................................ 124 Spis treÊci 7 Dodanie wäasnych typów MIME .................................................................................... 127 Rejestracja typów w Rails ...................................................................................... 128 Tworzenie wäasnego typu MIME .............................................................................. 129 Ograniczanie dostöpu do API w sposób zgodny z Rails ................................................... 129 Uwierzytelnienie uĔytkownika ................................................................................. 130 Algorytm ograniczajñcy .......................................................................................... 131 Wprowadzenie ograniczeþ za pomocñ filtrów ........................................................... 132 Co z usäugami SOAP i XML-RPC ................................................................................... 133 Interfejs usäugi ...................................................................................................... 134 Implementacja usäugi ............................................................................................ 135 Tworzenie struktur ................................................................................................. 136 Podsumowanie .......................................................................................................... 137 RozdziaÄ 6. Zasoby i REST .......................................................................................................................139 Sieè zasobów ............................................................................................................. 141 Identyfikacja zasobów ........................................................................................... 141 Mówienie o zasobach ............................................................................................ 142 Reprezentacja zasobów ......................................................................................... 142 REST ......................................................................................................................... 143 HTTP, czyli CRUD dla zasobów ............................................................................... 144 Definiowanie aplikacji w kategorii zasobów .............................................................. 146 Komunikacja z klientem, czyli zasoby jako API ......................................................... 151 Inny sposób, czyli sieè to komputer ........................................................................ 151 REST i Rails ............................................................................................................... 153 Odwzorowanie zasobów w routerze ......................................................................... 153 PoniewaĔ Ĉwiat nie jest idealny, nadal potrzebujemy odwzorowaþ nazwanych ............. 154 Automatycznie tworzone odwzorowania ................................................................... 156 Rusztowanie dla zasobów ...................................................................................... 158 ZagnieĔdĔone zasoby ............................................................................................. 158 Zasoby jako singletony czy zasoby tradycyjne .......................................................... 161 Podsumowanie .......................................................................................................... 162 RozdziaÄ 7. PiÂÀ stylów AJAX-a .............................................................................................................163 Wielkie sekrety .......................................................................................................... 165 Niekoniecznie AJAX stanowi najtrudniejszy element systemu .................................... 165 AJAX wymaga podjöcia trudnych decyzji projektowych .................................................... 166 Nawet w Rails moĔna zdecydowaè siö na wäasnñ bibliotekö JavaScriptu .................... 167 Piöè stylów AJAX-a ...................................................................................................... 169 Styl poĈrednika ..................................................................................................... 171 Styl fragmentowy .................................................................................................. 173 Styl marionetkowy ................................................................................................. 175 Kompilacja do JavaScriptu ..................................................................................... 177 Styl bezpoĈredniej edycji w aplikacji ........................................................................ 179 AJAX jako jeszcze jeden interfejs programistyczny ......................................................... 181 AJAX w stylu Rails ...................................................................................................... 183 Kontroler ajaksowy ze stylem fragmentowym (i AJAX CRUD) ...................................... 183 Kontrolery ajaksowe ze stylem marionetkowym (i RJS) ............................................. 186 Elegancka degradacja ................................................................................................. 189 Cofanie siö ze stylu fragmentowego ........................................................................ 189 Wycofywanie siö z bogatych interfejsów uĔytkownika ................................................ 191 Podsumowanie .......................................................................................................... 192 8 Rails. Sztuka programowania RozdziaÄ 8. Zabawa z blokami ................................................................................................................193 Bloki jako sposób programowania ............................................................................... 196 Porównanie metod, procedur i bloków .......................................................................... 200 Metody ................................................................................................................. 200 Procedury ............................................................................................................. 204 Bloki .................................................................................................................... 205 Przenoszenie siö miödzy blokami i procedurami ....................................................... 206 DuĔy eksperyment z zasiögiem .................................................................................... 207 Eksperyment 1. — na bloki wpäywa zmiana ich Ĉrodowiska Ēródäowego ..................... 208 Eksperyment 2. — bloki mogñ wpäynñè na Ĉrodowisko, z którego siö wywodzñ ........... 210 Wzorce blokowe i bloki w Rails .................................................................................... 212 Iteracja ................................................................................................................ 212 Programowanie aspektowe .................................................................................... 214 Tworzenie danych wyjĈciowych w HTML-u i XML-u ..................................................... 218 Funkcje o podwójnym zastosowaniu ........................................................................ 220 Wywoäania zwrotne ................................................................................................ 220 Podsumowanie .......................................................................................................... 222 RozdziaÄ 9. Mieszanie i Äatanie klas ......................................................................................................223 Doäñczenia ................................................................................................................. 225 Organizacja kodu w formie moduäów ....................................................................... 225 Metody w moduäach .............................................................................................. 227 Doäñczanie moduäów do klas .................................................................................. 228 Doäñczenia w Rails ................................................................................................ 232 Maäpie äatanie ............................................................................................................ 236 Metoda eval — tyle drzwi do interpretera ................................................................ 237 Rodzeþstwo metody eval ....................................................................................... 239 Dobra technika tworzenia äat .................................................................................. 245 Podsumowanie .......................................................................................................... 249 RozdziaÄ 10. Kod, który pisze kod (który pisze kod) ............................................................................251 Jeszcze raz o dynamicznym kodzie i DSL ...................................................................... 253 Makra piszñce kod ..................................................................................................... 254 Tworzenie metod w locie za pomocñ define_method ................................................ 254 Przykäad uĔycia define_method — Pentagon i Kreml ................................................. 255 Zasiög i define_method ......................................................................................... 257 Zastosowanie define_method w makrach Rails ........................................................ 258 Podsumowanie makr ............................................................................................. 260 Wywoäywanie nieistniejñcych metod — obiekty dostosowujñce siö do sposobów korzystania z nich ................................................................................ 261 Kilka prostych przykäadów ...................................................................................... 262 Przykäad — skrót dla Array.each ............................................................................. 263 UwaĔaj na wyäapywanie wszystkiego ....................................................................... 266 Wzorce metody method_missing ............................................................................ 267 Implementacja wzorców method_missing ................................................................ 268 Obiekty sterowane danymi — tworzenie täumacza komputerowego ............................ 272 Introspekcja ............................................................................................................... 274 Zmienne i staäe ..................................................................................................... 275 Metody ................................................................................................................. 276 Moduäy ................................................................................................................. 277 Podsumowanie .......................................................................................................... 278 Spis treÊci 9 RozdziaÄ 11. Jak przestaÄem si martwiÀ i pokochaÄem schemat bazy danych .................................279 Bazy danych w aplikacjach internetowych — stos LAMP ................................................ 280 MyĈlenie w kategoriach migracji .................................................................................. 282 Tworzenie migracji ................................................................................................. 284 Przeprowadzanie migracji danych ............................................................................ 286 Rozwój schematu w wiökszym zespole ......................................................................... 286 Populacja bazy danymi produkcyjnymi .......................................................................... 288 Niewielkie zestawy danych — populacja danych w migracji ....................................... 289 Zestawy danych Ĉredniej wielkoĈci — pliki danych ................................................... 290 DuĔe zestawy danych — pliki zrzutów bazy danych ................................................... 291 Gdy baza danych nie wystarcza .................................................................................... 293 Hierarchia obiektów modeli .................................................................................... 293 Przechowywanie list, säowników i innych elementów ................................................. 297 Wäasne funkcje pobierajñce i ustawiajñce ............................................................... 299 Podsumowanie .......................................................................................................... 300 RozdziaÄ 12. RSpec — programowanie sterowane zachowaniem ......................................................301 Programowanie sterowane zachowaniem ...................................................................... 303 RSpec — BDD dla Ruby on Rails ................................................................................. 305 Cykl programowania specyfikacji ............................................................................ 305 Pisanie specyfikacji ............................................................................................... 306 Implementacja przykäadów ..................................................................................... 308 Dopasowania ........................................................................................................ 309 Wäasne dopasowania ............................................................................................ 311 Przed i po ............................................................................................................. 313 Przykäadowy cykl programowania .................................................................................. 314 CzöĈè 1. Tworzenie historyjki ................................................................................. 314 CzöĈè 2. Tworzenie specyfikacji ............................................................................. 315 CzöĈè 3. Inicjalizacja i napisanie prostego testu ...................................................... 316 CzöĈè 4. Tworzenie testów zachowaþ motywujñcych do pisania kodu ........................ 318 CzöĈè 5. Uzupeänianie implementacji testów zachowaþ ............................................ 319 Ale to nie wszystko ..................................................................................................... 321 Podsumowanie .......................................................................................................... 322 Skorowidz ..............................................................................................................................................323 5 PiÂkne interfejsy aplikacji W. Web wysiadá z autobusu i nerwowo przeáknąá ĞlinĊ na widok ogromnego táoku i haáasu. Wysiadá jak najbliĪej placu aplikacji, czyli okoáo dwóch bloków dalej. W którąkolwiek stronĊ spojrzaá, widziaá mnóstwo URI i innych oficjeli trzymających transparenty i gáoĞno rozmawiających. „To trochĊ jak na meczu piáki noĪnej” — pomyĞlaá Web, przypominając sobie nagrania róĪnych wieców, które w niego wáoĪono przed wyjazdem. Powoli przeciskaá siĊ przez táum URI, starając siĊ dotrzeü bliĪej placu. URI byáy bardzo wysokie i szczupáe, przypominaáy nieco frytki z krótkimi nogami i ramionami jak u tyranozaurów. Z niewiadomych powodów wszystkie rozmawiaáy tak, jakby byáy z Bronksu, nawet te z Unikodu. Gdy grupy wygáaszaáy swoje slogany, ich nosowy gáos okresowo skrzeczaá przy bardziej ekscytujących je fragmentach. „Nie dziwi mnie, Īe te osoby to popychadáa” — pomyĞlaá Web. Prawdziwymi technokratami byli ci, którym nawet nie chciaáo siĊ rejestrowaü wáasnych nazw domen. Adresy IP lĞniáy na ich piersiach. Osoby z adresami IP byáy nieco bledsze i nosiáy okulary z grubymi szkáami. — UwaĪaj, facet! Czy nie moĪemy liczyü nawet na odrobinĊ szacunku na wáasnym proteĞcie? Web szukaá sceny tak intensywnie, Īe przypadkowo wpadá na jedną z takich osób. — Przepraszam… 208.97.177.118 — powiedziaá, starając siĊ tak odchyliü gáowĊ, by odczytaü adres IP. — Szukam gáównej sceny. Czy wiesz, gdzie siĊ znajduje? — A co ja, DNS? Ten zasób jest 301, przeniesiony na staáe! Ha, ha, ha, ha! — odwarknąá URI. Web staá jak wryty, bo nie wiedziaá, jak zareagowaü. 114 Rails. Sztuka programowania — Nie przejmuj siĊ, kolego. — URI poklepaá go po ramieniu. — To wspaniaáy dzieĔ. Scena jest tam — mówiąc to, pokazaá kierunek gáową. — DziĊkujĊ bardzo. Czy mógábyĞ mi powiedzieü, co jest powodem protestu? — Nikt nie daá ci ulotki? — odpowiedziaáa postaü. — Ach te dynamiczne URI! Nigdy nie moĪna liczyü, Īe bĊdą tam, gdzie siĊ ich spodziewasz. ĩądamy stabilizacji, poniewaĪ obecnie nie jesteĞmy szanowani, choü na to zasáugujemy. — Jak mam to rozumieü? — odrzeká Web. — Wszyscy was uĪywają. JesteĞcie wspaniali. PowinieneĞ widzieü, jak duĪy jest mój folder z zakáadkami! W zasadzie pewnego dnia… — UĪyjesz nas i odrzucisz, uĪyjesz i odrzucisz. Tak obecnie wygląda sytuacja. Czujemy siĊ jak odrzucane etykiety. Nikt nie chce zauwaĪyü naszej gáĊbi. Czy wydaje ci siĊ, Īe chcemy mieü 300 znaków dáugoĞci? Zapewne odpowiesz, Īe to nie ma znaczenia. Nikt nigdy nie zatrzymaá siĊ i nie zacząá podziwiaü piĊkna czystych adresów URI! Dlaczego? URI nie daá Webowi szansy odpowiedzi. — I usáugi spoáeczne — na nie równieĪ zasáugujemy. Czy wiesz, ile pieniĊdzy dostaáy w zeszáym roku testy jednostkowe? Ponad 1,2 miliarda. Miliarda! Zgadnij, ile my dostaliĞmy? Wielkie zero. Caákowite nic. Jak to siĊ dzieje, Īe to my jesteĞmy twarzą internetu, a nikt nie chce zwróciü na nas uwagi? Web wiedziaá juĪ, Īe to dopiero początek dáugiej tyrady, którą ten URI wygáaszaá juĪ wielokrotnie. Wiedziaá równieĪ, Īe musi dostaü siĊ na scenĊ, zanim skoĔczy siĊ protest. — W peáni siĊ z tym zgadzam. Zdecydowanie wiĊcej Ğrodków naleĪy przeznaczyü na URI — powiedziaá entuzjastycznie. — Sáuchaj, bardzo przepraszam, ale naprawdĊ muszĊ siĊ udaü na scenĊ. DziĊkujĊ za pomoc. Zanim URI zdąĪyá cokolwiek powiedzieü, Web wbiá siĊ w táum i zacząá siĊ przeciskaü w kierunku krawĊdzi placu. Ekscytującą cechą dobrego projektu jest to, Īe im bardziej siĊ w niego zagáĊbiasz, tym bardziej Ci siĊ podoba. W tym rozdziale postaram siĊ wskazaü, jak dobry projekt aplikacji stosującej model MVC szybko siĊ spáaca, gdy rozbudowujesz aplikacjĊ poza początkową wersjĊ. Niniej- szy rozdziaá skupia siĊ na projektowaniu, implementacji i mierzeniu internetowych interfejsów programistycznych. Oferowanie interfejsu programistycznego do aplikacji internetowej staje siĊ powoli istotnym elementem sukcesu. Daje uĪytkownikom lepszą kontrolĊ nad danymi i otwiera drzwi do kre- atywnego wykorzystania informacji. Choü nie moĪna mieü bezpoĞredniego zysku z reklam wyĞwietlanych na witrynach wykorzystujących dane z naszej witryny, pojawiają siĊ korzy- Ğci związane z ogólnym reklamowaniem serwisu przez uĪytkowników i zyskami z umów partnerskich. Internetowe interfejsy programistyczne promują wizjĊ internetu, w którym witryny mogą siĊ specjalizowaü i wspóápracowaü ze sobą, by lepiej i szybciej osiągaü cele programistyczne. Obecnie niewielu programistów tworzy wáasne systemy nanoszenia danych na mapĊ. Zamiast RozdziaÄ 5. Q PiÂkne interfejsy aplikacji 115 tego stosują doskonaáe interfejsy do map oferowanych przez Google, Yahoo! i Microsoft. CzĊĞci do wielokrotnego stosowania i moĪliwoĞü specjalizacji to kluczowe czynniki sprzyjające roz- wojowi nowych technologii. Tworzenie interfejsu dostĊpnego przez internet zwiĊksza jakoĞü i záoĪonoĞü aplikacji dla wszystkich uĪytkowników. Usáugi sieciowe to nieco mylący termin, poniewaĪ dotyczy zarówno ogólnej kategorii opro- gramowania, jak i bardzo wąskiej grupy standardów. Przypomina to trochĊ otwarcie nowej firmy produkującej i sprzedającej páatki owsiane i nazwanie jej „ĩywnoĞü”. Stosując tĊ nazwĊ, utrudnia siĊ jednoznaczną komunikacjĊ, poniewaĪ kaĪda osoba musi wskazaü, jaką ĪywnoĞü ma na myĞli: ĪywnoĞü lub ĩywnoĞü, a takĪe przypomnieü o róĪnicy. Z tego powodu w ksiąĪce uĪywam terminu „internetowe interfejsy programistyczne” (Web API). Niniejszy rozdziaá dotyczy Web API związanego z Ruby on Rails. Prezentuje styl tworzenia API w Rails, a takĪe sposoby udanego integrowania go z aplikacją. Poza drobnym fragmen- tem o ActionWebService na koĔcu rozdziaáu w ogóle nie wspominam o SOAP i XML-RPC, ale zajmujĊ siĊ raczej nowym stylem projektowania interfejsów programistycznych spopula- ryzowanym przez Rails. Styl ten stara siĊ traktowaü projektowanie wersji z interfejsem gra- ficznym i wersji jako usáugi sieciowej jako dwie strony tego samego systemu zamiast dwóch róĪnych, mocno oddzielonych komponentów. Dwa wielkie pomysÄy na Web API Ten rozdziaá skupia siĊ na dwóch wielkich pomysáach, które caákowicie zmieniáy sposób pro- jektowania i tworzenia internetowych interfejsów programistycznych. Dawniej adresy URL wskazywaáy na pliki ze zdalnego systemu plików, obecnie adresy URL z Īądania wskazują na wirtualne elementy aplikacji internetowej. Gdy zaczynamy organizowaü adresy URL wokóá tych wirtualnych elementów, a nie rzeczywistych plików, które je implementują, stają siĊ one znacznie prostsze do odczytania i znacznie elastyczniejsze. Drugim waĪnym elementem prezentowanym w rozdziale jest fakt, iĪ interfejs programistyczny to jedynie alternatywny format odpowiedzi dla juĪ istniejących akcji. JeĞli adres URL okreĞla funkcjonalnoĞü, a nie plik, wtedy ten sam adres URL moĪna zastosowaü do generowania danych w formacie HTML, XML, RDF lub nawet PDF. Wybór odpowiedniego formatu zaleĪy od nagáówków HTTP i rozszerzenia wskazanego w adresie URL, na przykáad .html lub .xml. To caákowicie nowy pomysá tworzenia interfejsów programistycznych, poniewaĪ w tej sytu- acji Web API i wáaĞciwa strona WWW są tym samym elementem, wspóádzielą kod i róĪnią siĊ jedynie sposobem wyĞwietlania wyników. Ten styl programowania prowadzi do mniejszej iloĞci kodu, gdyĪ eliminuje potrzebĊ powtarzania siĊ w momencie implementacji róĪnych wersji dostĊpu do usáugi. Nowy adres URL — adresacja zagadnieÆ, nie plików JeĞli kiedykolwiek uĪywaáeĞ witryny Flickr, zapewne zauwaĪyáeĞ áadny sposób zaprojekto- wania ich adresów URL. Na przykáad: http://flickr.com/photos/icygracy 116 Rails. Sztuka programowania KaĪda osoba z przynajmniej pobieĪną znajomoĞcią witryny Flickr poparzy na adres i od razu domyĞli siĊ, co znajdzie na stronie po jego wpisaniu. Ten adres moĪna zapamiĊtaü, zamiast tworzyü z niego zakáadkĊ, poniewaĪ stanowi pewien ĞciĞle okreĞlony wycinek przestrzeni adre- sowej stworzony celowo, a nie w wyniku ograniczeĔ oprogramowania. Adres oznacza: „ZdjĊ- cia uĪytkownika icygracy”. Adresy URL nie zawsze wyglądaáy tak elegancko, co moim zdaniem byáo jednym z wielu powo- dów powolnego rozprzestrzeniania siĊ w przeszáoĞci systemów Web API. Do niedawna trak- towano je jako efekt uboczny procesu programowania, a nie jako krytyczny element etapu projektowania. W szczególnoĞci: 1. Adres URL traktowano jako sposób lokalizacji kodu, który napisaá programista, a nie jako identyfikator pewnej konkretnej koncepcji. Dawniej adresy URL okreĞlaáy rzeczowniki, na przykáad /viewBook.php. To, jaką ksiąĪkĊ chcemy obejrzeü, przekazywano jako argument. Ten sposób tworzenia adresów URL oznaczaá, Īe traktowano je jako funkcje. Adresy same w sobie nie miaáy Īadnego gáĊbszego powiązania z ich uĪyciem. Stanowiáy caáoĞü dopiero w powiązaniu z parametrami. 2. Adresów URL nie projektowano, gdyĪ stanowiáy jedynie Ğrodek do osiągniĊcia innego celu. Powstawaáy w sposób organiczny jako czĊĞü struktury kodu lub organizacji serwera. 3. Adresy URL w sposób 1:1 odpowiadaáy plikom na serwerze, niezaleĪnie od tego, czy byáa to zawartoĞü statyczna, czy dynamiczna. Traktowanie adresu URL jako „piĊknego” oznacza, Īe jest on prosty na powierzchni, a jedno- czeĞnie mocno powiązany znaczeniowo z wykonywanym zadaniem. Jako archeologiczny artefakt obrazujący trzy wymienione powyĪej punkty warto przytoczyü áącze do towarów Dr. Seuss na witrynie Amazon.com z 2 marca 2000 roku: http://s1.amazon.com/exec/varzea/search-handle-url/ref=gw_m_col_7/?index= ´fixed- price 26rank=-price 26field-status=open 26field-browse= ´68457 26field- titledesc 3DDr. 20Seuss Ojej! Nie powinno dziwiü, Īe tworzenie usáug sieciowych traktowano jako dziaáalnoĞü caáko- wicie niezaleĪną od ich standardowych odpowiedników w postaci stron WWW. Czy nie lepiej byáoby zobrazowaü koncepcjĊ ksiąĪek Dr. Seuss w nastĊpujący sposób: http://amazon.com/authors/dr_seuss/books Przykáad jest nieco nieuczciwy. WczeĞniejszy adres URL zawiera kilka dodatkowych para- metrów okreĞlających sortowanie i typ elementów, ale nie wpáynĊáy one znacząco na wygląd adresu. Obecnie projektanci stron WWW uwaĪają, Īe lepiej tworzyü bardziej estetyczne i uĪy- teczne adresy URL wskazujące koncepcje wysokiego poziomu, a nie funkcje, które obsáu- gują te koncepcje. ĝcieĪka w stylu /authors/dr_seuss/books z pewnoĞcią okreĞla konkretną koncepcjĊ, wiĊc jest jednoznaczna dla programistów i uĪytkowników. ĝcieĪka /exec/varzea/ ´search-handle-url jest z pewnoĞcią ĞcieĪką do pewnego fragmentu kodu i nie ma wiĊkszego znaczenia dla wszystkich poza grupą programistów. Nowy sposób myĞlenia o adresach URL znacznie je oczyĞciá. Caákowicie zerwano z trakto- waniem adresów URL jako odwzorowaĔ na system plików. Zamiast odnosiü siĊ do obiektu RozdziaÄ 5. Q PiÂkne interfejsy aplikacji 117 w systemie plików, adres URL wyraĪa pewną koncepcjĊ związaną z moĪliwoĞciami aplikacji. Wymaga to dodatkowego kroku táumaczącego, nazywanego „kierowaniem”, który wkrótce omówimy. Oto, w jaki sposób, krok po kroku, nowe podejĞcie róĪni siĊ od starszego. 1. Adres URL widziany jako nakierowanie na pewną koncepcjĊ aplikacji, a nie na pewien fragment kodu aplikacji. MoĪe reprezentowaü zarówno rzeczowniki (zasoby zarządzane przez aplikacjĊ), jak i czasowniki (akcje wykonywane na tych zasobach). Adres URL ma znaczenie równieĪ bez parametrów, ale parametry mogą wpáynąü na sposób prezentacji lub zasady ustalania zbioru wyników. 2. Adres URL odwzorowujący koncepcjĊ aplikacji jest projektowany w ten sam sposób, co interfejsy obiektów w jĊzykach takich jak C++ lub Java. Struktura adresów URL powinna odpowiadaü konkretnym wzorcom zapewniającym czytelnoĞü i prostotĊ. Wzorce te spisuje siĊ i wymusza jako czĊĞü aplikacji. 3. Poza zawartoĞcią statyczną nie istnieje Īaden związek miĊdzy adresem URL i plikiem po stronie serwera. Adres URL okreĞla adresy koncepcji w wirtualnej przestrzeni, a w nie w systemie plików. W momencie otrzymania adresu URL nastĊpuje jego odwzorowanie na konkretny kod, który obsáuĪy Īądanie. Podstawowa sztuczka nie polega na tym, Īe pliki zaczyna siĊ organizowaü w inny sposób (prze- cieĪ na dyskach twardych serwerów witryny Flickr nie istnieje folder photos/icygracy/). Powstaje osobna warstwa abstrakcji na samym szczycie aplikacji internetowej sáuĪąca do adresacji poszczególnych funkcji. WczeĞniej adresy URL korzystaáy z warstwy abstrakcji zapewnianej przez system plików, czyli z plików i folderów, ale teraz wszystko organizuje siĊ wokóá pew- nego zbioru koncepcji. Choü kod aplikacji i jego struktura mają znaczenie dla programisty, to nie mają Īadnego znaczenia dla uĪytkowników. Nowa warstwa abstrakcji oznacza, Īe adresy URL bĊdą dla uĪytkowników przyjazne i jednoczeĞnie bĊdą miaáy okreĞlone znaczenie. Sam pomysá nie jest specyficzny dla Ruby on Rails. Sporo serwerów WWW, miĊdzy innymi Tomcat, umoĪliwia programistom tworzenie wielu kontekstów i procedur obsáugi, które pozwalają uelastyczniü adresy URL. Gdy serwer Tomcat wymaga setek wierszy kodu XML do poprawnej konfiguracji adresów URL, Rails wymaga jedynie dwóch lub trzech dziĊki zasto- sowaniu routera adresów. Zgodnie ze stylem Rails, odwzorowanie adresów na funkcje nie jest elementem opcjonalnym, ale wymuszonym. PoniewaĪ Rails czyni odwzorowanie prostym i wymaganym, powstają eleganckie, intuicyjne adresy URL, które wkrótce stają siĊ istotnym elementem caáej aplikacji. Aplikacja to interfejs Drugi gáówny pomysá polega na tym, Īe to aplikacja jest internetowym interfejsem programi- stycznym, bo tak naprawdĊ byáa nim od początku. KaĪde pobranie strony to wywoáanie w Īądaniu pewnego interfejsu, który w odpowiedzi zwraca kod HTML. W zasadzie dochodzi do generowania kodu HTML tylko dlatego, Īe takiej odpowiedzi spodziewa siĊ przeglądarka internetowa. Równie dobrze dane strony moĪna by przedstawiü w postaci pliku tekstowego, XML, RDF lub dowolnego innego formatu. JeĞli wprowadziáeĞ w Īycie pierwszy pomysá — adresy URL wyraĪają koncepcje, a nie pliki — zrobiáeĞ ogromny krok w przód, by zapewniü jednolity interfejs dla stron WWW i interfejsu 118 Rails. Sztuka programowania Web API. Tworząc strony WWW wokóá adresów URI bazujących na koncepcjach, w zasadzie wykonaáeĞ „interfejs” dostĊpowy równieĪ dla systemów zautomatyzowanych. Teraz wystarczy juĪ tylko zaimplementowaü przygotowywanie odpowiedzi w postaciach innych niĪ od HTML. Powstaáy kod aplikacji internetowej potrafi generowaü wyniki ĪądaĔ HTTP w wielu róĪnych formatach. Witryna zaprojektowana wáaĞnie w ten sposób jest bardzo wygodna dla programisty. JeĞli trzeba obsáuĪyü zwracanie danych w postaci plików CSV, wystarczy tylko zdefiniowaü wygląd pliku CSV i dodaü opcjĊ obsáugi tego formatu w kontrolerze. To wáaĞnie ten rodzaj podziaáu ról, który zapewnia architektura MVC. Dalsza czĊĞü rozdziaáu prezentuje sposoby implementacji akcji kontrolera, które potrafią same zdecydowaü o sposobie formatowania wyników. JeĞli w przyszáoĞci ludzie zapytają, czy pla- nujesz dodaü do witryny interfejs programistyczny, moĪesz siĊ uĞmiechnąü i powiedzieü: „on juĪ tam jest”. Odwzorowania adresów Odwzorowania adresów to nowy gracz, dziĊki któremu moĪliwe staje siĊ wygodne tworzenie interfejsów Web API. Odwzorowanie odpowiada za dopasowanie i zamianĊ Īądania HTTP na wywoáanie okreĞlonego kodu (w przypadku Rails akcji kontrolera), który wygeneruje odpo- wiedĨ. Rails analizuje otrzymany adres URL wzglĊdem serii wpisów podanych w pliku config/ routes.rb. Ten krok odwzorowujący jest niezbĊdny do przeksztaácenia adresów URL z odnie- sieĔ do plików na identyfikatory koncepcji. Po przejĞciu przez router adres wskazuje pewną przestrzeĔ koncepcyjną, a nie plik w systemie plików. Oto jak dziaáa proces odwzorowania: w momencie nadejĞcia nowego Īądania, serwer WWW sprawdza, czy dotyczy ono pliku statycznego, bo jego ĞcieĪka znajduje siĊ w folderze public/. JeĞli tak, adres URL traktuje siĊ jako lokalizacjĊ pliku w lokalnym systemie plików i wysyáa jego zawartoĞü do uĪytkownika. To podejĞcie zapewni zgodnoĞü wsteczną z tradycyjnym sys- temem adresów URL. JeĞli ĞcieĪka nie pasuje do pliku w folderze public/, Īądanie trafia do Rails, gdzie router stara siĊ je dopasowaü do jednego z istniejących odwzorowaĔ. Proces odwzorowania wykorzystuje seriĊ definicji, które okreĞlają wzorce adresów URL — na nie powinna reagowaü aplikacja. KaĪde odwzorowanie to wzorzec do wypeánienia — przypo- mina to trochĊ grĊ Mad Libs dostosowaną do adresów URL. Porównywanie adresu do wzorca nastĊpuje w kolejnoĞci ich wystĊpowania w pliku routes.rb. To pierwsze dopasowanie decy- duje o tym, jak Īądanie zostanie obsáuĪone. Od strony koncepcyjnej system Route Libs wygląda tak jak na rysunku 5.1. Rozbicie adresu URL na elementy nie jest moĪliwe, jeĞli aplikacja stosuje odwzorowanie adre- sów na strukturĊ folderów i plików. W Ğwiecie nakierowanym na dokumenty adres URL to po prostu ĞcieĪka wzglĊdem pewnego ustalonego folderu bazowego. W systemie z routerem adres URL dopasowuje siĊ do szablonu pewnych koncepcji, którym odpowiadają okreĞlone akcje. Rysunek 5.1 RozdziaÄ 5. Q PiÂkne interfejsy aplikacji 119 Odwzorowanie skáada siĊ z trzech czĊĞci: 1. nazwy, 2. szablonu, 3. sáownika wartoĞci domyĞlnych i walidatorów. Te trzy elementy tworzą razem kod o nastĊpującej postaci: map.connect photos/:user_handle/:photoset , :controller = photos , :action = list Nazwa odwzorowania to nazwa metody wywoáywanej dla obiektu map. JeĞli wywoáamy map.user do utworzenia odwzorowania, zwiąĪe siĊ ono z nazwą user i dodatkowo uzyskamy w kodzie dostĊp do takich metod, jak user_url i path_for_user. Odwzorowanie map.recipe stworzyáoby nową nazwĊ recipe. JeĞli nie chcemy podawaü nazwy dla odwzorowania (czasem nie ma ku temu powodów), stosujemy domyĞlną metodĊ map.connect, która tworzy odwzoro- wane nienazwane. NastĊpnym elementem w definicji jest szablon odwzorowania. W zaprezentowanym przy- káadzie jest to photos/:user_handle/:photoset. KaĪdy segment adresu rozpoczynający siĊ od dwukropka oznacza zmienną do wypeánienia — odpowiada to pustym miejscom w grze Mad Libs. Wszystkie inne segmenty muszą wystąpiü bez Īadnych modyfikacji. ĝcieĪka w stylu /my/super/secret/page definiuje odwzorowanie, które nie zawiera w sobie Īadnej zmiennoĞci; adres URL musi pasowaü co do joty. Odwzorowanie w stylu secret/:code dopasuje siĊ do wielu róĪnych adresów URL — dowolnej dwusegmentowej ĞcieĪki, która zaczyna siĊ tekstem secret/ i koĔczy inną zmienną. JeĞli dojdzie do dopasowania, kontroler otrzyma jedną zmienną w postaci params[:code]. W Rails niektóre nazwy zmiennych są zarezerwowane do celów specjalnych, a niektóre są wrĊcz wymagane. KaĪde odwzorowanie musi definiowaü zmienną :controller czy to jako zmienną szablonu w definicji ĞcieĪki, czy jako sáownik opcji (prezentowany poniĪej). Zmienna :action równieĪ ma specjalne znaczenie, poniewaĪ definiuje akcje kontrolera, która naleĪy wywoáaü w momencie odpowiedzi na Īądanie. JeĞli zmienna ta nie pojawi siĊ w definicji odwzorowania, Rails zaáoĪy, Īe powinna przyjąü wartoĞü index. JeĞli akcja index nie istnieje w kontrolerze, Rails zgáosi báąd. Opcjonalna zmienna :format okreĞla poĪądany format odpowiedzi, który jest nie- zaleĪnym od typu MIME sposobem wskazania preferowanej metody uzyskania odpowiedzi. MoĪliwoĞü tak szybkiego wprowadzenia typów odpowiedzi do adresów URL stanowi jeden z powodów wyjątkowo áatwego tworzenia interfejsu programistycznego witryny. 120 Rails. Sztuka programowania Trzecim komponentem definicji jest opcjonalny sáownik zawierający dodatkowe ustawienia odwzorowania, miĊdzy innymi wartoĞci domyĞlne i walidacje. Sáownik czĊsto zawiera wartoĞci domyĞlne dla zmiennych, które mogą nie pojawiü siĊ w szablonie ĞcieĪki. Poprzedni przykáad ustawia zmienną :controller na wartoĞü photos. Sáownik moĪe takĪe zawieraü ograniczenia co do formatu danych poszczególnych fragmentów ĞcieĪki zamienianych na zmienne poda- wane w postaci wyraĪeĔ regularnych. Te dodatkowe wyraĪenia regularne mogą spowodowaü niedopasowanie siĊ adresu URL do odwzorowania, zmniejszając liczbĊ potrzebnych spraw- dzeĔ. Wymóg, by wszystkie identyfikatory byáy liczbami, to doskonaáy przykáad przeniesienia sprawdzenia z kodu kontrolera lub modelu do odwzorowaĔ. Plik routes.rb powinien byü przyjemnym, áatwym w odczycie plikiem z adresami URL: # Odwzorowuje adresy w stylu /dinner/12 na akcjú Recipe::Feature, # ustawiajæc parametr dinner_feature_id. map.connect dinner/:dinner_feature_id , :controller = recipe , :action = feature # Odwzorowuje kalendarz uľytkownika. Stosuje domyħlny rok, miesiæc i dzieē. map.connect user/:user_id/calendar/:year/:month/:day , :controller = calendar , :action = view , :year = Time.now.year, :month = Time.now.month, :day = Time.now.day # Odwzorowuje adresy w postaci /A/B/C na akcjú A::B z parametrem ID=C. map.connect :controller/:action/:id’ PoniewaĪ plik routes.rb stanowi poáączenie miĊdzy wszystkimi niestatycznymi Īądaniami HTTP i kodem aplikacji, áatwo zauwaĪyü, Īe projektowanie adresów URL to bardzo waĪny krok w trakcie tworzenia aplikacji Rails. Nawet najdalsze zakamarki witryny WWW muszą mieü zdefiniowane odwzorowanie. Odwzorowania to zatem publiczny interfejs aplikacji, nawet jeĞli domyĞlnie zwracają tylko kod HTML. W takim interfejsie metody prywatne i chronione wyko- nujące niskopoziomowe zadania są caákowicie ukryte przed uĪytkownikiem. Podobnie dzieje siĊ w przypadki interfejsu Web API, który caákowicie ukrywa przed uĪytkow- nikiem rzeczywistą strukturĊ plików aplikacji — adresy URL i pliki istniejące na serwerze, które obsáugują te adresy, są od siebie caákowicie odseparowane. Choü szablony adresów URL dają ogromną swobodĊ, zawsze pamiĊtaj o staraniu siĊ, by byáy przewidywalne i proste. Unikaj tworzenia bardzo dáugich odwzorowaĔ z mnóstwem parame- trów, bo wtedy adresy URL wcale nie bĊdą lepsze od adresów z koĔca lat 90. XX wieku. Klu- czem jest prostota: zredukuj aplikacjĊ do podstawowych koncepcji, którymi są zainteresowani uĪytkownicy, i wykonywanych na nich akcjach. Wszystko inne — informacje dookreĞlające, takie jak sposób sortowania, kody referencyjne i stron wyników wyszukiwania — powinno byü przekazywane jako parametry URL. W ten sposób adres URL zawsze reprezentuje konkretną koncepcjĊ, a parametry to jedynie dodatkowy i opcjonalny tryb uszczegóáowienia Īądania. W rozdziale 6. pojawią siĊ dodatkowe wskazówki związane z tym tematem, poniewaĪ w duĪej mierze dotyczy on rozbicia interfejsu publicznego na koncepcje zwane zasobami. RozdziaÄ 5. Q PiÂkne interfejsy aplikacji 121 Anatomia wywoÄania Web API Odwzorowania adresów URL otwierają drzwi do interfejsów programistycznych bazujących na HTTP i przyjaznych dla uĪytkownika, które reprezentowane są przez wirtualne zakoĔcze- nia obsáugujące okreĞloną funkcjonalnoĞü. ZakoĔczenia nie wystarczają jednak do wykonania peánego wywoáania Web API. Z tego powodu wywoáanie skáada siĊ z czterech komponentów. Cztery komponenty wymienione w poniĪszej tabeli wyglądają bardzo podobnie do komponen- tów tradycyjnego wywoáania metody, ale z kilkoma wyjątkami. Wywoáanie funkcji okreĞla typ zwracanej odpowiedzi, a polecenie HTTP trafia do wywoáania metody jako czĊĞü sterująca jej wykonaniem. Komponent Zapewniany przez Cel Kontroler i akcja. DefinicjĊ odwzorowania. Wybranie odpowiedniej klasy kontrolera i wykonanie znajdującej siĊ w niej metody w odpowiedzi na nadesáane Īądanie. OkreĞla, jaki format odpowiedzi naleĪy zapewniü. Zapewnia dodatkowe parametry pozwalające wypeániü podstawowe Īądanie. Zakáada podstawową naturĊ Īądania: pobieranie danych, ich modyfikacja, dodanie lub usuniĊcie. Format odpowiedzi. Nagáówki HTTP lub Parametry Īądania. Polecenie HTTP. definicjĊ odwzorowania (zmienna :format). Dane formularza lub parametry adresu URL. ĩądanie HTTP. Odwzorowania to jedynie czĊĞü wiĊkszego systemu. Witryna WWW to zbiór zakoĔczeĔ zde- finiowanych i udostĊpnianych przy uĪyciu czterech komponentów zdefiniowanych w tabeli. NajczĊĞciej zakoĔczenia zwracają dane w postaci kodu HTML, ale z racji moĪliwoĞci okreĞle- nia alternatywnego formatu mogą równieĪ dziaáaü jako interfejs programistyczny. W nastĊpnym punkcie przyjrzymy siĊ obsáudze przez tĊ samą akcjĊ wielu formatów danych. Kolidujñce, a czasem niezgodne punkty widzenia Powróè do tej czöĈci rozdziaäu 5. po przeczytaniu rozdziaäu 6., zwiñzanego z architek- turñ REST. Pomysäy dotyczñce Web API prezentowane tutaj róĔniñ siö nieco od propo- zycji z nastöpnego rozdziaäu. ēadne z rozwiñzaþ nie jest zdecydowanie lepsze. KaĔde ma swoje wady i zalety, prowadzi do nieco innego sposobu traktowania aplikacji. NakÄadanie API Po zaprojektowaniu wzorców URL reprezentujących koncepcje i akcje aplikacji internetowej czas wprowadziü formaty odpowiedzi róĪne od HTML do tych samych mechanizmów, które generują strony WWW. Nakáadanie API przypomina tworzenie nowe widoku witryny, ale tym razem te nowe, alternatywne wyniki są najprawdopodobniej generowane dynamicznie, a nie 122 Rails. Sztuka programowania przechowywane w postaci plików ERB. NaáoĪenie API wymaga dwóch kroków: najpierw trzeba zapewniü reagowanie widoku na zgáoszenia róĪnych formatów danych, a nastĊpnie upew- niü siĊ, Īe widok potrafi wygenerowaü odpowiedĨ w formacie wskazanym przez uĪytkownika. Metoda respond_to Szkielet ActionController zapewnia kontrolery z bardzo sprytną metodą o nazwie respond_to, która znacznie upraszcza generowanie odpowiedzi w róĪnych formatach na podstawie tej samej akcji. Metoda tworzy obiekt, który áatwo wykorzystaü do okreĞlenia kodu, który ma siĊ wyko- naü tylko w przypadku poproszenia o konkretny format danych. Zastosowanie metody respond_to uáatwia rozdzielenie wáaĞciwej implementacji akcji od czĊ- Ğci odpowiedzialnej za wygenerowanie odpowiedzi. Najlepiej najpierw wykonaü wszystkie prace związane z wáaĞciwą akcją, a dopiero na samym koĔcu skorzystaü z bloku respond_to, by zwróciü wynik w wymaganym formacie. PoniĪszy kod stanowi przykáad zastosowania tej strategii: class SomeController def action # --------------------------------------- # Wykonaj dziađania wđaħciwe dla akcji. # --------------------------------------- # Nastúpnie przygotuj wynik w formacie wskazanym przez uľytkownika. respond_to do |:type| type.html { # Najczúħciej puste ciađo bloku. } type.xml { # Najczúħciej wywođanie .to_xml. } type.rdf { # Najczúħciej wywođanie .to_rdf. } type.js { # Najczúħciej fragment RHTML lub szablon RJS. } end end end Ten szablon dziaáa bardzo dobrze, bo stara siĊ zawrzeü w bloku respond_to wszystkie moĪ- liwe formaty odpowiedzi. Oto, w jaki sposób wygląda szablon po zastosowaniu go w rzeczy- wistej akcji kontrolera, w tym przypadku w akcji przeglądania zdjĊcia: class PhotoController def show @photo = Photo.find(params[:id]) # Ustawienie zmiennej wymaganej przez widok. respond_to do |:type| # Zrenderuj widok w wymaganym formacie. type.html {} # Domyħlnie uľyj formatu RHTML. type.xml { render :xml = @photo.to_xml } type.rdf { render :rdf = @photo.to_rdf } # Wymaga dodatku acts_as_rdf. type.js { render :partial = photo , :locals = {:photo = @photo } end end end RozdziaÄ 5. Q PiÂkne interfejsy aplikacji 123 Jedyną operacją wykonywaną przez akcjĊ jest znajdowanie zdjĊcia. Samo wyĞwietlenie zdjĊ- cia obsáuguje kod widoku wywoáywany przez akcjĊ. Gdyby trzeba byáo zmieniü sposób znaj- dowania zdjĊcia (bo jego identyfikator bĊdzie powiązany z uĪytkownikiem), wystarczy wpro- wadziü poprawkĊ tylko w jednym miejscu dla wszystkich formatów odpowiedzi. Czasem operacja wykonywana przez akcjĊ jest znacznie bardziej záoĪona niĪ proste wczytanie zdjĊcia. Trzeba byü przygotowanym do wyáapania báĊdów, które mogą wystąpiü, i na wyĞwie- tlenie komunikatów báĊdów w odpowiednim formacie. Obsáuga báĊdów nieco psuje nam nasz wyidealizowany Ğwiat respond_to: w jaki sposób uniezaleĪniü siĊ od szczegóáów formatu odpowiedzi, skoro w pewnych sytuacjach báąd moĪe wystąpiü w poáowie akcji? Na szczĊĞcie istnieje rozwiązanie tego problemu. Przypomnij sobie poprzedni rozdziaá — mówiáem w nim o technice, która osadza wiĊkszoĞü ciĊĪkiej funkcjonalnoĞci w warstwie modelu i wykorzystuje wáasne wyjątki do zgáaszania báĊ- dów. Stosując tĊ strategiĊ obsáugi báĊdów oraz wáasne wyjątki z dobrze napisanymi komuni- katami, powstanie system pozwalający utrzymaü prostotĊ akcji. Zamiast wypeániaü kod akcji kolejnymi warstwami warunków sprawdzających báĊdy, two- rzymy obiekty modeli, które zgáaszają wyjątki, gdy tylko zostaną zauwaĪone. W ten sposób masz pewnoĞü, Īe wszystko, co do tej pory wykonaáeĞ, powiodáo siĊ, wiĊc nie musisz wprowadzaü dodatkowych sprawdzeĔ. Wiesz jednak, Īe poza sceną system zgáosi wyjątek, gdy tylko napo- tka istotny báąd. Aby obsáuĪyü sytuacje wyjątkowe, otocz kod akcji blokiem rescue, który przechwyci wyjątek i zgáosi go uĪytkownikowi w sposób zaleĪny od wskazanego formatu wyników. Oto szablon wieloformatowej akcji wraz z obsáugą báĊdów. ZauwaĪ, Īe kod jest bardzo podobny do wczeĞniejszego, ale wybór formatów odpowiedzi pojawia siĊ dwukrotnie — raz dla stan- dardowej odpowiedzi i raz dla sytuacji wyjątkowej: class SomeController def action # --------------------------------------- # Podstawowe zadania wykonywane przez akcjú. # --------------------------------------- # Po ich przeprowadzeniu wygeneruj wynik w odpowiednim formacie. respond_to do |:type| type.html { # Najczúħciej pusty blok. } type.xml { # Najczúħciej wywođanie .to_xml. } type.js { # Najczúħciej fragment RHTML lub szablon RJS. } end rescue = err # Ojej! Wystæpiđ bđæd, wiúc wygeneruj odpowiedni wynik. respond_to do |:type| type.html { # Najczúħciej przekierowanie z komunikatem. } type.xml { # Najczúħciej struktura z bđúdem lub bđæd HTTP. } type.js { # Najczúħciej bezpieczna odpowiedļ specyficzna dla akcji # wraz z komunikatem bazujæcym na JavaScripcie. } end end end 124 Rails. Sztuka programowania Podobnie jak w przypadku kaĪdego wzorca, szablon ten nie stanowi panaceum na wszystkie moĪliwe báĊdy. Z pewnoĞcią pojawią siĊ sytuacje wymagające dokáadniejszego obsáuĪenia w akcjach kontrolera, by zapewniü najbardziej odpowiednie zachowanie. Ten podstawowy szablon stanowi solidną podstawĊ, dziĊki której moĪna zapewniü prostotĊ kodu akcji. UĪywając bloku respond_to, zamieniamy odwzorowania, które kiedyĞ stanowiáy zakoĔczenia witryny WWW, w coĞ na ksztaát programowych zakoĔczeĔ aplikacji WWW. Po dobrym zapro- jektowaniu witryny niewiele pracy trzeba wáoĪyü, by istniejące akcje obsáugiwaáy inne formaty danych, na przykáad XML. Implementacja akcji juĪ istnieje, wiĊc wystarczy jedynie zdefinio- waü sposób konwersji wyników akcji na odpowiedni format. Zapis wyniku w formacie innym niÑ HTML Tworzenie wyników w formatach innych niĪ HTML jest czĊsto áatwiejsze od tworzenia strony HTML, poniewaĪ jesteĞ zainteresowany jedynie surowymi danymi (chyba Īe tworzysz wyniki dla medium wizualnego takiego jak PDF). Caáy proces staje siĊ znacznie bardziej záoĪony niĪ HTML, gdy juĪ bardzo szczegóáowo okreĞlisz format publicznego API. Gdy zmiany w wyglą- dzie HTML moĪna wprowadziü w dowolnym momencie bez powaĪnych efektów ubocznych, zmiana struktury XML moĪe doprowadziü do traumatycznych przeĪyü wielu uĪytkowników API. PostĊpuj bardzo ostroĪnie w trakcie prac na projektem formatu danych XML lub RDF, gdyĪ generalnie bardzo trudno bĊdzie zmieniü zdanie po upublicznieniu usáugi. Ta czĊĞü rozdziaáu opisuje trzy formaty danych, których zapewne chciaábyĞ uĪyü jako API: XML, RSS i RDF. Grupowanie XML, RSS i RDF PuryĈci zapewne stwierdzñ, Ĕe grupowanie XML, RSS i RDF przypomina nieco grupowanie jabäek i pomaraþczy. XML to skäadnia reprezentacji danych, RDF to model koncepcyjny dla danych bazujñcych na grafach, które moĔna opisaè jözykiem XML, a RSS to standard rozpowszechniania informacji, który równieĔ korzysta z jözyka XML. Pomimo róĔnej natury grupowanie ich razem ma sens, poniewaĔ z punktu widzenia API to obecnie trzy najwaĔ- niejsze formaty danych stosowane w internecie. XML JeĞli nie przejmujesz siĊ tym, Īe dokumenty XML bĊdą dokáadnie odpowiadaáy schematowi bazy danych, tworzenie wyników w postaci kodu XML w aplikacji Rails moĪe skróciü siĊ do jednego wiersza. KaĪdy obiekt ActiveRecord zawiera metodĊ to_xml, która przechodzi przez wszystkie pola obiektu i zapisuje je jako znaczniki XML, wiĊc blok respond_to w postaci: @user = User.find(params[:id]) respond_to do |:type| type.xml { render :xml = @user.to_xml } end spowoduje wygenerowanie nastĊpującego kodu: user first_name Jan /first_name RozdziaÄ 5. Q PiÂkne interfejsy aplikacji 125 last_name Kowalski /last_name address ... /address /user Funkcja to_xml przyjmuje dodatkowo sáownik opcji, który moĪe albo ograniczyü liczbĊ pól umieszczanych w kodzie XML, albo rozszerzyü szeregowanie na powiązane obiekty modeli. Przekazanie sáownika :include = [ :asocjacja1, :asocjacja2] spowoduje, Īe system zapi- sujący przejdzie dodatkowo przez asocjacje i doáączy je do wynikowego kodu XML. Najprostszym sposobem dostosowania wyniku XML do wáasnych potrzeb (poza automa- tycznie generowanym kodem przez ActiveRecord) jest uĪycie szablonów RXML. Pliki te są bardzo podobne do plików RHTML i znajdują siĊ w tym samym miejscu w strukturze projektu, ale korzystają z rozwiązania nazwanego Builder zamiast ActionView. Pliki RXML to standardowe pliki w jĊzyku Ruby, które otrzymują egzemplarz klasy Builder o nazwie xml i wykorzystują go do utworzenia dokumentu XML. Niech rozszerzenie CiĊ nie zmyli — są to pliki stosujące podejĞcie z kodowaniem najpierw. Gdy wynikiem pliku RHTML jest renderowanie wszystkiego poza znacznikami . . . , wynikiem dokumentu RXML jest zbiór wywoáaĔ metod zmiennej xml. Innymi sáowy, pliki RHTML stosują podejĞcie z dokumentem najpierw, a pliki RXML z kodem najpierw. Aby utworzyü znacznik, po prostu wywoáaj nazwĊ znacznika jako metodĊ obiektu Builder. Ta metoda w rzeczywistoĞci nie istnieje, ale powoduje wywoáanie procedury method_missing, którą system tworzenia XML traktuje jako instrukcjĊ do utworzenia nowego znacznika. Sposób programowania wykorzystujący procedurĊ method_missing opiszĊ w rozdziale 10. Wygląd znacznika zaleĪy od sposobu wywoáania metody: Q Zastosowanie metody bez argumentów tworzy znacznik pusty, wiĊc xml.br tworzy br / . Q Po podaniu argumentu system tworzy znacznik zawierający wartoĞü tekstową, wiĊc xml.h1( Witaj! ) tworzy kod h1 Witaj! /h1 . Atrybuty podaje siĊ jako sáownik umieszczony w ostatnim argumencie dowolnego wywoáania metody tworzącej znacznik. Utworzenie hiperáącza za pomocą kodu wymaga napisania poniĪszego tekstu: xml.a Witryna Wydawnictwa Helion , :href = http://helion.pl Q Po przekazaniu bloku system tworzy element zawierający dowolne znaczniki utworzone w tym bloku, wiĊc polecenie: xml.people { xml.person { xml.first_name( Jan ) } } spowoduje wygenerowanie kodu: people person first_name Jan /first_name /person /people 126 Rails. Sztuka programowania Wystarczy poáączyü te trzy zachowania razem, by uzyskaü wszystkie klocki potrzebne do zbudowania dokumentu XML o dowolnej záoĪonoĞci. OczywiĞcie istnieją pewne dodatkowe elementy, takie jak deklaracja typu dokumentu, komentarze XML itp., wiĊc warto wczeĞniej zajrzeü do dokumentacji klasy Builder dostĊpnej pod adresem http://builder.rubyforge.org/. RSS Kanaáy RSS zapewniają bardzo waĪny sposób luĨnego powiązania witryny z jej uĪytkowni- kami. CzĊsto uĪytkownik nie chce odwiedzaü bloga lub innej aplikacji kaĪdego dnia, ale jest zainteresowany powiadomieniem o wystąpieniu na niej nowych elementów. Stosując czytnik RSS, uĪytkownik automatycznie dowiaduje siĊ o wszystkich istotnych zmianach na witrynie i moĪe zdecydowaü, czy chce ją odwiedziü, czy teĪ nie. Tworzenie kanaáu RSS dla aplikacji Rails to doskonaáe üwiczenie uczące RXML, gdyĪ to wáa- Ğnie dziĊki niemu wykonuje siĊ tego rodzaju prace. Zacznijmy od zaprezentowania szablonu z kanaáem RSS 2.0, który zawiera jeden artykuá z bloga: ?xm
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Rails. Sztuka programowania
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ą: