1 Co obejmuje przewodnik?
Ten przewodnik jest przeznaczony dla początkujących, którzy chcą rozpocząć tworzenie aplikacji opartych na Railsach. Nie zakłada, że masz wcześniejsze doświadczenia z Railsami. Niemniej jednak, do najlepszego wykorzystania tego przewodnika, konieczna jest instalacja:
- języka Ruby
- RubyGems – narzędzie do dystrybuowania i instalowania paczek zawierających moduły i rozszerzenia języka Ruby
- systemu zarządzania bazą danych SQLite (preferowane), MySQL lub PostgreSQL
Zdecydowanie zaleca się zapoznanie z językiem Ruby przed rozpoczęciem przygody z Railsami. Znacznie łatwiej jest śledzić, co się dzieje w Railsach, rozumiejąc podstawowy składni języka Ruby. Railsy nie będą w stanie w magiczny sposób zrewolucjonizować sztuki pisania aplikacji internetowych, jeżeli nie masz doświadczenia w używaniu tego języka. W Internecie istnieje kilka dobrych darmowych źródeł pomocnych w nauce języka Ruby, w tym:
- Mr. Neigborly’s Humble Little Ruby Book
- Programming Ruby
- Why’s (Poignant) Guide to Ruby
- Wprowadzenie do języka Ruby
2 Co to są Railsy?
Railsy są frameworkiem służącym do tworzenia aplikacji internetowych napisanym w języku Ruby. Zostały one tak zaprojektowane, aby ułatwić programowanie aplikacji internetowych, poprzez przyjęcie kilku założeń, dotyczących tego czego potrzebuje każdy programista aby rozpocząć pracę. Pozwalają one na pisanie krótszego kodu, jednocześnie umożliwiając osiąganie lepszych rezultatów niż ma to miejsce w większości innych języków i frameworków. Poza tym programiści, którzy od dawna używają Railsów, uważają, że pisanie aplikacji z ich użyciem sprawia prawdziwą przyjemność.
Railsy są “upartym” oprogramowaniem. Oznacza to, że były tworzone z przekonaniem, że istnieje najlepszy sposób rozwiązywania pewnych problemów i zostały zaprojektowane tak, by zachęcać do wyboru tego sposobu, a w niektórych przypadkach – by zniechęcić do wyboru alternatywy. Jeśli nauczysz się “The Rails Way”, odkryjesz ogromny wzrost produktywności. Jeżeli jednak podczas pracy z Railsami pozostaniesz przy nawykach charakterystycznych dla programowania w innych językach lub będziesz wykorzystywać wzorce, których już kiedyś się nauczyłeś, efekty mogą nie być aż tak pomyślne.
Filozofia Railsów obejmuje kilka zasad:
- DRY – “Don’t Repeat Yourself” (Nie powtarzaj się) – sugeruje, że pisanie w kółko tego samego kodu jest po prostu złe.
- “Convention over Configuration” (Konwencja Ponad Konfiguracją) – Railsy przyjmują pewne założenia, odnośnie tego, co i jak zamierzasz zrobić, dlatego nie zmuszają Cię do samodzielnego ustawiania każdej najdrobniejszej opcji w plikach konfiguracyjnych.
- REST (Representational State Transfer) jest najlepszym wzorcem dla aplikacji internetowych – organizowanie aplikacji wokół zasobów i standardowych zapytań HTTP pozwala szybko kroczyć do przodu.
2.1 Architektura MVC
Railsy zorganizowane są wokół trzech warstw aplikacji: modelu (model ), widoku (view ) oraz kontrolera (controller ), w skrócie nazywanych MVC. Wzorzec MVC obejmuje:
- odizolowanie logiki biznesowej od interfejsu użytkownika
- łatwość utrzymania kodu zgodnie z zasadą DRY
- wyraźne wskazanie, gdzie powinny znajdować się różne elementy kodu, co ułatwia zarządzenie nim
2.1.1 Modele
Model reprezentuje dane aplikacji i reguły do manipulowania tymi danymi. W przypadku Railsów, modele są głównie wykorzystywane do zarządzania zasadami interakcji z odpowiednią tabelą bazy danych. W większości przypadków jednej tabeli bazy danych odpowiada jeden model. Większość logiki biznesowej aplikacji będzie skoncentrowana w modelach.
2.1.2 Widoki
Widoki tworzą interfejs użytkownika aplikacji. W Railsach widoki są często plikami HTML zawierającymi kod w języku Ruby, wykonujący zadania związane wyłącznie z prezentacją danych. Przede wszystkim są one odpowiedzialne za dostarczanie danych do przeglądarki internetowej lub innego narzędzia, które jest używane do oglądania efektów działania aplikacji.
2.1.3 Kontrolery
Kontrolery “sklejają” modele i widoki. W Railsach odpowiadają za przetwarzanie żądań przychodzących z przeglądarki internetowej, pozyskiwanie danych z modeli i przekazywanie ich do widoków w celu ich prezentacji.
2.2 Składniki Railsów
Railsy dostarczają zestaw komponentów do tworzenia aplikacji internetowych. Są to:
- Action Controller
- Action View
- Active Record
- Action Mailer
- Active Resource
- Railties
- Active Support
2.2.1 Action Controller
Moduł Action Controller jest komponentem zarządzającym kontrolerami. Action Controller przetwarza przychodzące zapytania, wydobywa z nich parametry i wysyła je do odpowiedniej akcji. Usługi świadczone przez Action Controller obejmują zarządzanie sesją, renderowanie widoków i zarządzanie przekierowaniami.
2.2.2 Action View
Moduł Action View zarządza widokami. Może domyślnie tworzyć zarówno widok HTML jak i XML. Action View zarządza renderowaniem szablonów (w tym szablonami zagnieżdżonymi oraz podszablonami) i dostarcza wsparcie dla AJAXa.
2.2.3 Active Record
Moduł Active Record jest podstawowym elementem warstwy modelu. Zapewnia niezależność od bazy danych, dostarcza podstawowe funkcjonalności CRUD (create, read, update and delete – utwórz, odczytaj, aktualizuj, usuń), zaawansowane możliwości wyszukiwania i zdolność do wiązania modeli a także wiele innych usług.
2.2.4 Action Mailer
Moduł Action Mailer służ do tworzenia usług e-mail. Action Mailer może być używany do wysyłania e-maili w oparciu o elastyczne szablony lub do odbioru i przetwarzania przychodzących wiadomości.
2.2.5 Active Resource
Moduł Active Resource pozwala na zarządzanie powiązaniami pomiędzy obiektami biznesowymi oraz internetowymi serwisami RESTful. Implementuje mapowanie zasobów internetowych na obiekty lokalne w oparciu o semantykę CRUD.
2.2.6 Railties
Moduł Railties jest rdzeniem kodu Rails, służącym do tworzenia nowych aplikacje i łączenia w nich poszczególnych elementów frameworku.
2.2.7 Active Support
Moduł Active Support jest obszernym zbiorem użytecznych klas oraz rozszerzeń standardowych bibliotek języka Ruby, które są wykorzystywane w Railsach, zarówno przez rdzeń kodu, jak i Twoją aplikację.
2.3 REST
Praca doktorska Roya Fieldinga Architectural Styles and the Design of Network-based Software Architectures jest powszechnie uznawana za fundament architektury RESTful. Na szczęście, nie musisz czytać tego dokumentu w całości, aby zrozumieć, jak działa REST w Rails. REST (Representational State Transfer) jest stylem architektury oprogramowania sprowadzającym się do dwóch podstawowych zasad:
- Korzystanie z identyfikatorów zasobów (które na potrzeby tego przewodnika możesz traktować jako adresy URL) do reprezentowania zasobów.
- Przesyłanie reprezentacji stanu zasobów pomiędzy elementami systemu.
Na przykład, dla aplikacja Railsowej następujące żądanie:
DELETE /photos/17będzie rozumiane jako odnoszące się do zdjęcia o ID 17 oraz jako wskazanie żądanego działania – usunięcie tego zasoby. REST jest naturalnym stylem architektury aplikacji internetowych, który Railsy czynią jeszcze bardziej intuicyjnym, poprzez korzystanie z konwencji, pozwalających na nieprzejmowanie się jego złożonością oraz różnicami pomiędzy przeglądarkami.
Jeśli chciałbyś dowiedzieć się czegoś więcej na temat REST jako stylu architektonicznego, polecam bardziej przystępne źródła od pracy Fieldinga:
- Krótkie wprowadzenie do REST Stefana Tilkov
- Wprowadzenie do REST – Joe Gregorio (video)
- REST – artykuł w Wikipedii
3 Tworzenie nowego projektu w Railsach
Z pomocą tego przewodnika, będziesz mógł utworzyć projekt prostego bloga w Railsach. Zanim przystąpisz do tworzenia aplikacji, upewnij się jednak, że masz zainstalowane Railsy.
3.1 Instalacja środowiska Rails
W większości przypadków, najprostszym sposobem zainstalowania Railsów jest skorzystania z RubyGems:
$ gem install rails
Istnieją pewne szczególne okoliczności, w których można zastosować alternatywną strategię instalacji:
- Jeśli pracujesz w systemie Windows, będzie Ci łatwiej zainstalować Instant Rails. Pamiętaj jednak, że Instant Rails rzadko zawierają aktualną wersją Railsów. Ponadto, Windowsowa wersja Railsów jest ogólnie mniej przyjazna w użytkowaniu niż te przeznaczone dla innych systemów operacyjnych. Jeśli to możliwe, polecamy korzystanie z Linuksowej maszyny wirtualnej.
- Jeżeli chcesz być na bieżąco z najnowszymi zmianami w środowisku Rails, proponujemy skopiowanie kodu źródłowego z githuba, aczkolwiek nie jest to opcja zalecana dla początkujących.
3.2 Tworzenie bloga
Otwórz terminal i przejdź do folderu, w którym posiadasz odpowiednie uprawnienia do tworzenia plików, a następnie wpisz polecenie:
$ rails new blog
To stworzy Railsową aplikację, która korzysta z bazy danych SQLite. Jeśli wolisz korzystać z MySQL, wywołaj zamiast niego polecenie:
$ rails blog -d mysql
A jeśli używasz PostgreSQL do przechowywania danych, zastosuj polecenie:
$ rails blog -d postgresql
Uruchamiając rails -h możesz zobaczyć wszystkie akceptowane opcje.
Po utworzeniu aplikacji, aby móc kontynuować pracę, przejdź do odpowiedniego folderu:
$ cd blog
Railsy utworzą folder o nazwie blog w katalogu roboczym. Otwórz ten folder i przyjrzyj się jego zawartości. Podczas pracy z tym przewodnikiem, w większości będziemy korzystać z folderu app/, ale poniżej możesz zapoznać się z podstawowymi funkcjami katalogów i plików, które domyślnie utworzą Railsy.
Plik/Katalog | Przeznaczenie |
---|---|
README | Jest to krótka instrukcja dla danej aplikacji. Za jej pomocą możesz poinformować innych o tym, jak działa Twoja aplikacja i jak ją można uruchomić. |
Rakefile | Plik ten zawiera listę zadań, które można uruchomić w linii poleceń. |
app/ | Folder zawiera kontrolery, modele i widoki dla danej aplikacji. Na tym folderze będziemy koncentrować się w dalszej części tego przewodnika. |
config/ | Folder zawierający pliki konfiguracyjne aplikacji, obejmujące zmienne czasu uruchomienia, konfigurację bazę danych, ścieżki dostępu etc. |
db/ | Pokazuje aktualny schemat bazy danych, jak również jego migracje (o których niedługo będziesz się uczyć). |
doc/ | Dokumentacja aplikacji. |
lib/ | Dodatkowe moduły aplikacji (nieuwzględnione w tym przewodniku). |
log/ | Logi aplikacji. |
public/ | Jedyny całkowicie dostępny publicznie folder. Zawiera wszelkie zdjęcia, JavaScript, arkusze stylów (CSS) i inne statyczne pliki. |
script/ | Skrypty dostarczone przez Rails w celu uproszczenia powtarzających się zadań, takich jak benchmarking, instalowanie wtyczek (plugin) i uruchamianiu konsoli lub serwera WWW |
test/ | Testy jednostkowe, tak zwane “fixtures” oraz inne narzędzia służące do przeprowadzania testów. Są one opisane w: Testowanie aplikacji Rails |
tmp/ | Pliki tymczasowe |
vendor/ | Miejsce na kod, którego sami nie napisaliśmy, ale chcemy wykorzystać. W standardowej aplikacji Rails mogą znaleźć się tutaj Ruby Gems, kod źródłowy Railsów (jeśli zainstalujesz go w swoim projekcie) i wszystkie dodatkowe wtyczki z gotowym kodem. |
3.3 Konfiguracja bazy danych
Prawie każda aplikacja Railsowa korzysta z bazy danych. Rodzaj baza danych, której używamy, jest określony w pliku konfiguracyjnym config/database.yml. Jeśli otworzysz ten plik w nowej aplikacji Railsowej, zostanie wyświetlona domyślna konfiguracja bazy danych SQLite. Plik zawiera sekcje dla trzech różnych środowisk, w których Railsy mogą być domyślnie uruchomione:
- środowisko development (rozwojowe) jest używane na komputerze programisty, aby mógł oglądać bezpośrednio rezultaty wprowadzanych zmian
- środowisko test (testowe) służy do uruchamiania automatycznych testów
- środowisko production (produkcyjne) jest używane kiedy aplikacja uruchomiona jest na serwerze produkcyjnym
3.3.1 Konfiguracja bazy danych SQLite
Railsy mają wbudowaną obsługę SQLite, który jest lekkim, pozbawionym serwera systemem zarządzania bazą danych. Mimo możliwości przeciążenia SQLite’a w środowisku produkcyjne, działa on zadowalająco podczas pisania programu oraz testów. Railsy domyślnie używają SQLite przy tworzeniu nowego projektu, ale zawsze można to zmienić.
Poniżej znajduje się część domyślnej konfiguracji pliku z ustawieniami dla środowiska rozwojowego:
development:
adapter: sqlite3
database: db/development.sqlite3
timeout: 5000
Jeśli nie masz żadnej zainstalowanej bazy danych, najłatwiej będzie Ci skorzystać z SQLite’a, w czym mogą być pomocne Ruby Gems (posiadacze Maca z OS X w wersji 10.5 lub nowszej mają go zainstalowanego domyślnie):
$ gem install sqlite3-ruby
3.3.2 Konfiguracja bazy danych MySQL
Jeżeli zdecydujesz się na używanie bazy danych MySQL, Twój plik config/database.yml będzie wyglądał trochę inaczej:
development:
adapter: mysql2
encoding: utf8
database: blog_development
username: root
password:
socket: /tmp/mysql.sock
Ta konfiguracja powinna działać bez problemu, jeśli Twoja instalacja MySQLa nie ma wprowadzonego hasła dla super-użytkownika (root user). Jeśli jednak jest inaczej, koniecznie zmień nazwę użytkownika oraz hasło w powyższym kodzie.
3.3.3 Konfiguracja Bazy Danych PostgreSQL
Używając PostgreSQL Twój plik config/database.yml powinien zostać zmodyfikowany do pracy z tą bazą danych:
development:
adapter: postgresql
encoding: unicode
database: blog_development
username: blog
password:
Konieczna jest zmiana nazwy użytkownika oraz hasła w konfiguracji środowiska rozwojowego.
3.3.4 Tworzenie Bazy Danych
Teraz, gdy masz już skonfigurowaną bazę danych, czas by Railsy stworzyły dla ciebie pustą bazę danych. Możesz to zrobić uruchamiając komendę rake:
$ rake db:create
Rake jest poleceniem ogólnego zastosowania, które Railsy
używają do wielu rzeczy. By zobaczyć listę dostępnych komend uruchom rake -T.
4 Witajcie Railsy!
Jednym z tradycyjnych sposobów uczenia się nowego języka jest pobieżne przeglądnięcie jego tekstu. By tak zrobić w Railsach, konieczne jest stworzenie przynajmniej kontrolera oraz widoku. Na szczęście możesz to zrobić używając pojedynczej komendy, wpisując ją do terminala:
$ script/generate controller home index
Jeżeli używasz systemu Windows lub gdy twój Ruby jest skonfigurowany w
niestandardowy sposób, możliwe że będziesz musiał przekazać komendę script bezpośrednio do Ruby’ego: ruby script/generate controller home index.
Railsy stworzyły dla Ciebie kilka plików, włączając w to app/views/home/index.html.erb - szablon, który będzie używany do pokazywania efektów akcji index w kontrolerze home. Otwórz ten plik w edytorze tekstów i dopisz do niego tę pojedynczą linijkę kodu:
<h1>Hello, Rails!</h1>
4.1 Uruchamianie serwera WWW
Teraz, za pomocą jedynie dwóch komend, masz gotowy i działający Railsowy program! Będziesz mógł go zobaczyć w przeglądarce uruchamiając go za pomocą komendy:
$ script/server
Domyślnie spowoduje to odpalenie instancji serwera aplikacyjnego Mongrel (Railsy mogą wykorzystywać kilka innych serwerów aplikacji). By zobaczyć jak działa Twój program, otwórz okno przeglądarki i przejdź pod adres http://localhost:3000. Powinieneś zobaczyć domyślną stronę informacyjną:
By zatrzymać serwer WWW naciśnij Ctrl+C w oknie terminala podczas jego działania.
Generalnie Railsy działające w trybie rozwojowym, po wprowadzeniu zmian w Twoich plikach, nie wymagają zatrzymywania serwera – zostaną one automatycznie zauważone przez serwer.
Ekran powitalny jest pierwszym testem dla nowego programu napisanego w Railsach – upewnia nas, że oprogramowanie którym dysponujemy, jest poprawnie skonfigurowane. Aby zobaczyć nowoutworzoną stronę, przejdź pod adres http://localhost:3000/home/index.
4.2 Konfiguracja strony domowej programu
Prawdopodobnie chcesz zamienić domyślną stronę startową ze stroną Twojego programu. Pierwszym krokiem jest wykasowanie z katalogu public strony domyślnej:
$ rm public/index.html
Powinieneś teraz wskazać Railsom gdzie jest zlokalizowana Twoja strona domowa. Otwórz plik config/routes.rb w edytorze – jest to plik routingu. Zawiera wpisy w specjalnym DSLu (Domain Specific Language – specyficzny język domenowy), które pokazują Railsom w jaki sposób przekształcić adres wprowadzony w przeglądarce na odpowiednie akcje kontrolerów. Na dole tego pliku znajdują się dwie domyślne drogi:
map.connect ':controller/:action/:id'
map.connect ':controller/:action/:id.:format'
Domyślne drogi obsługują proste żądania, takie jak /home/index: Railsy tłumaczą je na wywołanie akcji index w kontrolerze home. Kolejny przykład, /posts/edit/1 uruchomi akcję edit w kontrolerze posts z parametrem id równym 1.
By połączyć Twoją stronę domową, musisz dodać jeden wpis do pliku routingu, powyżej drogi domyślnej:
map.root :controller => "home"
Ta linijka ilustruje jeden mały kawałek podejścia “konwencja ponad konfiguracją”: jeżeli nie podasz żadnej akcji, Railsy uruchomią domyślnie akcję index.
Po przejściu do strony http://localhost:3000 , zobaczysz widok home/index .
Więcej informacji na temat routingu znajdziesz w przewodniku
5 Szybki start dzięki rusztowaniu.
Railsowe rusztowanie (scaffolding) jest szybkim sposobem na napisanie znacznej części programu. Jeśli chcesz stworzyć modele, widoki i kontrolery dla nowych zasobów w pojedynczej operacji, to jest to odpowiednie narzędzie dla Ciebie.
6 Tworzenie zasobu
W przypadku programów takich jak blog, możesz zacząć od stworzenia zasobu Post z rusztowaniem, który będzie reprezentował pojedynczy wpis w blogu. Aby to zrobić, wprowadź następującą komendę w terminalu:
$ script/generate scaffold Post name:string title:string content:text
Chociaż rusztowanie pozwoli Ci szybko rozpocząć pisanie programu, ten uniwersalny
kod raczej nie będzie idealnie pasować do Twojej aplikacji. W większości przypadków będziesz musiał samodzielnie dokonać w nim zmian. Wielu doświadczonych programistów Rails unika używania rusztowań na rzecz pisania większości kodu źródłowego od podstaw, bez używania gotowych wzorców.
Generator rusztowania utworzy w Twoim programie 14 plików, wspólnie z paroma folderami i jeden dodatkowo zmodyfikuje. Oto krótki przegląd tego co tworzy powyższa komenda:
Plink | Przeznaczenie |
---|---|
app/models/post.rb | Model dla posta |
db/migrate/20081013124235_create_posts.rb | Migracja do tworzenia tabeli postów w bazie danych (nazwa która pojawi się u Ciebie będzie zawierała inny znacznik czasowy) |
app/views/posts/index.html.erb | Widok indeksu wszystkich postów |
app/views/posts/show.html.erb | Widok pojedynczego posta |
app/views/posts/new.html.erb | Widok tworzenia nowego posta |
app/views/posts/edit.html.erb | Widok edycji posta |
app/views/layouts/posts.html.erb | Widok określający całościowy wygląd i działanie innych widoków dla postów |
public/stylesheets/scaffold.css | Arkusz stylów poprawiający wygląd widoków w rusztowaniu |
app/controllers/posts_controller.rb | Kontroler postów |
test/functional/posts_controller_test.rb | Testy funkcjonalności dla kontrolera postów |
app/helpers/posts_helper.rb | Helpery używane w widokach postów |
config/routes.rb | Modyfikacja polegająca na uwzględnieniu postów w routingu |
test/fixtures/posts.yml | Posty testowe |
test/unit/post_test.rb | Testy jednostkowe dla modelu postów |
test/unit/helpers/posts_helper_test.rb | Testy jednostkowe dla helpera dla postów |
6.1 Uruchamianie Migracji
Jednym z produktów komendy: script/generate scaffold jest migracja bazy danych. Migracje są klasami Rubiego, które upraszczają tworzenie i modyfikowanie tabel baz danych. Railsy używają komend rake’a do uruchamiania migracji i pozwalają na wycofywanie ich po tym, jak zostały zaaplikowane w bazie danych. Nazwy plików migracji zawierają znaczniki czasowe, by zapewnić ich przetwarzanie w porządku, w jakim zostały utworzone.
Gdy zajrzysz do pliku db/migrate/20090113124235_create_posts.rb (jego nazwa może się u Ciebie trochę różnić), zobaczysz następującą zawartość:
class CreatePosts < ActiveRecord::Migration
def self.up
create_table :posts do |t|
t.string :name
t.string :title
t.text :content
t.timestamps
end
end
def self.down
drop_table :posts
end
end
Gdybyś chciał ująć ten kod w słowa, brzmiałby on mniej więcej tak: gdy migracja jest uruchomiona, tworzy tabelę o nazwie posts z dwoma kolumnami zawierającymi łańcuchy znaków (name i title) i jedną kolumną tekstową (content), a wraz z nimi kolumny znaczników czasu, by śledzić czas jej utworzenia oraz ostatniej aktualizacji. Więcej szczegółów na temat sposobu pisania migracji znajdziesz w przewodniku Migracje.
Teraz możesz użyć komendy rake by wprowadzić migracje do bazy danych:
$ rake db:create
$ rake db:migrate
Ponieważ domyślnie pracujesz w środowisku rozwojowym, ta komenda wykona się na bazie danych zdefiniowanej w sekcji development pliku: config/database.yml.
6.2 Dodawanie hiperłącza
By połączyć posty ze stroną domową, którą już stworzyłeś, możesz dodać do niej hiperłącze. Otwórz plik /app/views/home/index.html.erb i dopisz do niego:
<h1>Hello, Rails!</h1>
<%= link_to "My Blog", posts_path %>
Metoda link_to jest jednym z wbudowanych helperów dla widoków. Tworzy ona link z tekstem do wyświetlenia oraz informacją, gdzie prowadzi – w tym wypadku ze ścieżką do posta.
6.3 Praca z postami w przeglądarce
Teraz jesteś już gotowy do pracy z postami. Na początek przejdź do: http://localhost:3000 i kliknij w link My Blog.
image:./images/posts_index.png[Posts Index screenshot]
Jest to rezultat renderowania Twoich postów z użyciem widoku index. Aktualnie nie ma żadnych wpisów w bazie danych, ale zawsze możesz je utworzyć klikając w link New Post. Możesz również przeglądać i edytować posty, a nawet je wykasować. Cały logika i HTML stworzone były za pomocą pojedynczego polecenia script/generate scaffold.
W środowisku rozwojowym (na nim domyślnie pracujesz) z każdym żądaniem
przeglądarki Railsy wgrywają od nowa program, dzięki czemu nie jest konieczne restartowanie serwera WWW.
Gratulacje! Napisałeś swoją pierwszą aplikację w Railsach! Nadszedł czas, aby przyjrzeć się efektom pracy.
6.4 Model
Zawartość pliku modelu app/models/post.rb jest niemal tak samo prosta jak jego utworzenie:
class Post < ActiveRecord::Base
end
Nie zawiera on zbyt wiele treści – zauważ jednak że klasa Post dziedziczy z ActiveRecord::Base. Moduł Active Record za darmo dostarcza wielu funkcji dla Twoich modeli, włączając w to podstawowe operacje na danych CRUD (create, read, update, delete) czy weryfikowanie danych, jak również wsparcie dla zaawansowanego wyszukiwania i zdolność do wiązania ze sobą wielu różnych modeli.
6.5 Sprawdzanie poprawności danych
Railsy są wyposażone w metody, które pomogą Ci sprawdzić poprawność danych wysyłanych do modeli. Wprowadź poniższe zmiany do pliku: app/models/post.rb
class Post < ActiveRecord::Base
validates_presence_of :name, :title
validates_length_of :title, :minimum => 5
end
Dzięki nim mamy pewność, że każdy post będzie mieć nazwę oraz tytuł, a ten ostatni nie będzie miał mniej niż 5 znaków. Railsy mogą sprawdzać różne warunki w modelu, włączając w to obecność lub unikalność kolumn, ich format i istnienie związanych z nimi obiektów.
6.6 Używanie konsoli
By zobaczyć, jak sprawdzanie poprawności danych działa w praktyce, użyjemy konsoli. Konsola, będąca narzędziem linii poleceń, umożliwia Ci wykonywanie kodu Rubiego w kontekście Twojej aplikacji:
$ script/console
Możesz jej użyć do pracy z modelami:
>> p = Post.create(:content => "A new post")
=> #<Post id: nil, name: nil, title: nil, content: "A new post",
created_at: nil, updated_at: nil>
>> p.save
=> false
>> p.errors
=> #<ActiveRecord::Errors:0x23bcf0c @base=#<Post id: nil, name: nil,
title: nil, content: "A new post", created_at: nil, updated_at: nil>,
@errors={"name"=>["can't be blank"], "title"=>["can't be blank",
"is too short (minimum is 5 characters)"]}>
Powyższy kod przedstawia informację, jaką otrzymasz, gdy chcesz utworzyć nowy, ale błędny Post. Mechanizm jest następujący: przy próbie zapisania pojawia się wartość zwrotna false (oznaczającą, że zapisanie się nie powiodło), a kod wyszczególnia nam wszystkie znalezione błędy w postaci errors.
W przeciwieństwie do serwera WWW, konsola nie wczytuje automatycznie
zmian w Twoim kodzie. By wczytać wprowadzone zmiany z poziomu konsoli, musisz użyć komendy reload!
6.7 Wyświetlanie postów
Najłatwiejszym sposobem na zapoznanie się z funkcjonalnościami programu jest przyjrzenie się kodowi, który wyświetla wszystkie posty. Otwórz plik: app/controllers/posts_controller.rb i przyjrzyj się akcji index
def index
@posts = Post.find(:all)
respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @posts }
end
end
Powyższy kod przypisuje do zmiennej instancyjnej @posts tablicę wszystkich postów z bazy danych. Post.find(:all) lub Post.all wywołuje metodę klasową w modelu Post, która zwraca wszystkie posty z bazy danych, bez nakładania żadnych warunków.
Więcej informacji na temat znajdowania rekordów za pomocą Active Record znajdziesz
w przewodniku Zapytania w module Active Record
Blok respond_to obsługuje obydwa typy wywołań tej akcji – zarówno HTML jak i XML. Jeśli przejdziesz pod adres http://localhost:3000/posts.xml, to zobaczysz wszystkie posty w formacie XML. Natomiast format HTML poszukuje widoku w app/views/posts, nazwanego tak samo jak odpowiadająca mu akcja. Railsy zaś przenoszą wszystkie zmienne instancyjne (zaczynające się od znaku @) zainicjowane w akcji do widoku. Oto zawartość app/view/posts/index.html.erb:
<h1>Listing posts</h1>
<table>
<tr>
<th>Name</th>
<th>Title</th>
<th>Content</th>
</tr>
<% for post in @posts %>
<tr>
<td><%=h post.name %></td>
<td><%=h post.title %></td>
<td><%=h post.content %></td>
<td><%= link_to 'Show', post %></td>
<td><%= link_to 'Edit', edit_post_path(post) %></td>
<td><%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table>
<br />
<%= link_to 'New post', new_post_path %>
Widok iteruje po zawartości tablicy @posts, pokazując treść postów oraz linki. Zwróć uwagę na następujące elementy:
- h to helper, który oczyszcza wyświetlane dane, zapobiegający atakom typu “cross-site scripting”
- link_to buduje link do określonej lokalizacji
- edit_post_path jest helperem, który Railsy udostępniają w ramach routingu RESTful. Zobaczysz jeszcze sporo różnych rodzajów takich helperów dla wielu akcji z kontrolerów.
Więcej szczegółów na temat procesu renderowania znajdziesz w przewodniku
6.8 Dostosowanie layoutu
Przetwarzanie widoku stanowi tylko część złożonego procesu, którego efektem jest utworzenie wynikowej strony HTML. Railsy wyposażone są również w layouty, które stanowią pojemniki na widoki. Renderowanie widoku odbywa się poprzez umieszczanie kodu HTML widoku wewnątrz kodu HTML layoutu. Komenda script/generate scaffold automatycznie utworzyła domyślny layout dla postów: app/views/layouts/posts.html.erb. Otwórz go w swoim edytorze i zmodyfikuj tag body:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
<title>Posts: <%= controller.action_name %></title>
<%= stylesheet_link_tag 'scaffold' %>
</head>
<body style="background: #EEEEEE;">
<p style="color: green"><%= flash[:notice] %></p>
<%= yield %>
</body>