На мінулым занятку мы стварылі стандартны каркас Rails прыкладання. Давайце падрабязней пазнаёмімся са структурай. Большая частка працы падчас распрацоўкі будзе з файламі каталога app/, але варта пазнаёміцца і з астатнімі файламі і дырэкторыямі, каб лепей разумець, як працуе Rails application.
app/assets/ змяшчае рэсурсы вашага прыкладання: выявы, файлы JavaScript і стылі CSS.
app/models/, app/views/, app/controllers/ - код вашых мадэляў, прадстаўленняў і кантроллераў. Пра Model-Views-Controllers чытайце ніжэй.
app/helpers/ - тут прынята змяшчаць модулі з дапаможнымі метадамі для прадстаўленняў вашага прыкладання. Па першае, гэта дае магчымасць разгрузіць views ад логікі і складанай рэалізацыі, па другое, гэта дазваляе пазбегнуць паўтораў у кодзе.
bin/ захоўвае бінарныя скрыпты, якія выконваюць запуск прыкладння і іншыя задачы (наладка, deploy, rake). Сюды можна дадаваць і свае сцэнары для каманднага радка.
config/ змяшчае ўсе наладкі вашага прыкладання і кампанентаў Rails. Тут можна сканфігураваць асяроддзі распрацоўкі (config/environments/), альбо зрабіць агульныя для ўсіх асяроддзяў канфігурацыі (application.rb). Таксама тут змяшчаюцца канфігі базы дадзеных і іншыя (assets, middleware, генератары, лакалізацыя, разгортванне). Звярніце увагу на каталог config/initializers/ - тут змешчаны ініцыялізатары. Гэта Ruby-файлы, код якіх выконваецца пасля загрузкі фрэймўорка і гемаў. З файлам config/routes.rb/ пазнаёмімся крыху пазней.
Я ўжо адзначаў, што па змоўчванні Rails прыкладанне сканфігураванна адпаведна разумным пагаджэнням. Вы можаце ў гэтым запэўніцца, калі паглядзіце колькі ўжо канфігурацыйных файлаў і дырэкторый было створана ў каталоге app/config/, калі мы згенеравалі прыкладанне. Ткім чынам пачатковая канфігурацыя ўжо зроблена для вас. Тым не менш, вы заўсёды можаце змяніць пэўныя наладкі адпаведна сваім канкрэтным задачам. Больш падрабязна з канфігурацыяй Rails прыкладанняў можна у Rails Guides.
db - тут захоўваюцца файлы базы дадзеных: міграцыі, seed-файлы, схема базы.
lib/ - знешнія модулі для прыкладання, vendor/ - код пабочных распрацоўшчыкаў (бібліятэкі, плагіны, рэсурсы).
log/ - логі прыкладання, tmp/ - часовыя файлы. Не забывайце дадаваць гэтыя каталогі у .gitignore
public/ - гэта адзіная дырэкторыя, якая даступная знешне, таму трэба быць асцярожным і ўзважваць размяшчэнне і доступ да файлаў гэтага каталога. Тут звычайна захоўваюцца статычныя файлы (старонкі памылак, мапа сайта і г.д).
test/ - тут месцяцца тэсты для Rails прыкладання. config.ru - канфігурацыя для Rack middleware. Rakefile - службовыя rake-каманды, якія можна запускаць з тэрмінала. README.rdoc - мануал і дакументацыя для вашага прыкладання. Я рэкамендую змяшчаць тут інструкцыі па наладцы вашага прыкладання ці мануал па запуску нейкіх спецыфічных задач. Добрая дакументацыя дазволіць сэканоміць шмат часу вам і вашым калегам. Звярніце увагу, што Github паказвае змесціва Readme, калі зайсці на старонку рэпазіторыя. З .gitignore, Gemfile і Gemfile.lock мы пазнаёміліся на мінулым занятку.
Канцэпцыя Model-View-Controller была апісана яшчэ у 1979 годзе, падчас працы над мовай Smalltalk. Варта заўважыць, што мова Ruby і фрэймўорк Rails ўвабралі ў сябе шмат добрых рэчаў з іншых тэхналогій. Паглядзіце на выдатную інфаграфіку, якая паказвае ўзаемасувязі паміж Ruby і іншымі мовамі праграмавання.
MVC - гэта архітэктура прыкладання, адпаведна якой адбываецца падзяленне логікі прыкладання на тры кампаненты:
- Model - бізнэс-логіка.
- View - логіка прадстаўлення даступная карыстальніку у графічным выглядзе
- Controller - логіка самаго прыкладання
Што гэта азначае ў кантэксце Ruby on Rails? У Rails ёсць чоткае падзяленне на кампаненты MVC.
Мадэлі Rails - гэта класы Ruby, якія адказваюць за дадзеныя, прадстаўленне, валідацыю, актуальнасць і апрацоўку дадзеных, а таксама ўзаемасувязі паміж дадзенымі. Мадэлі камунікуюць з БД праз сродкі Active Record.
Views (прадстаўленні) - гэта шаблоны, якія адказваюць за візуалізацыю. У канечным выглядзе яны канвертуюцца ў HTML старонкі.
Кантроллеры ўзаемадзейнічаюць з мадэлямі. Таксама кантроллеры апрацоўваюць запыты карыстальнікаў і вяртаюць адказ ў выглядзе статычнай вэб старонкі, альбо (пасля выкліка мадэлі) - вяртаюць прадстаўленне з візуялізаванымі дадзенымі.
Зараз мы паглядзім на практыцы, як рэалізавана MVC у Rails. Для гэтага мы створым Pages кантроллер і дададзім некалькі статычных старонак.
Генеруем кантроллер (Pages - гэта назва кантроллера, home і course - гэта назвы actions (дзеянняў):
$ rails generate controller Pages home course
Акрамя уласна файла кантроллера каманда rails generate стварае заглушкі для скрыптаў, стыляў, тэстаў і хэлпераў. Таксама дадаецца шаблон і абнаўляюцца маршруты.
Адчыніце ў браўзеры http://0.0.0.0:3000/pages/home - гэта старонка, якую мы толькі што згенеравалі. Давайце зробім яе галоўнай старонкай. Для гэтага трэба дадаць карнявы маршрут:
# config/routes.rb
root 'pages#home'
Радок get 'pages/home' цяпер можна выдаліць. За перадачу запытаў ад кліента да
нашага прыкладання адказвае Rails router. Давайце расшыфруем радок
root 'pages#home'. Мы толькі што сказалі роўтэру, як паступаць з запытам да
кораня (root) нашага прыкладання - http://0.0.0.0:3000/ . Роўтэр накіроўвае
гэты запыт да дзеянне home кантроллера pages. Але паглядзіце файл нашага
кантроллера: дзеянне home пустое. Давайце дададзім крыху дадзеных:
# app/controllers/pages_controller.rb
def home
@hello = 'Hi there!'
end
Мы толькі што стварылі зменную экземпляра @hello і далі ёй значэнне радка Hi there!. Радкі у Ruby змяшчаюцца ў апострафах. Давайце перададзім значэнне зменнай на нашу home старонку:
# app/views/pages/home.html.erb
<h1><%= @hello %></h1>
Звярніце ўвагу, што файл View мае фармат html.erb. erb - гэта Embedded Ruby,
фільтр, які дазваляе выконваць код Ruby ў нашых прадстаўленнях. Ў erb-файлах код,
які выконваецца і вынік якога мусіць быць адлюстраваны змяшчаецца ў канструкцыі
<%= %>. Сюды мы і запіхалі нашу зменную.
Акрамя home action мы маем таксама course. Гэта дзеянне выклікаецца пры запыце http://0.0.0.0:3000/pages/course. Давайце спрасцім запыт, для гэтага зменім стары маршрут на іменаваны:
# config/routes.rb
get 'course' => 'pages#course'
Што гэта значыць? Мы далі імя course для нашага дзеяння course кантроллера pages. Зараз гэта дзеянне можна выклікаць такім чынам: http://0.0.0.0:3000/course
Давайце створым яшчэ адну старонку - для водгукаў на нашым будучым сайце:
# app/views/pages/testimonials.html.erb
<h1>Testimonials</h1>
Калі адразу паспрабаваць адчыніць яе http://0.0.0.0:3000/pages/testimonials - мы атрымаем памылку ActionController::RoutingError (No route matches [GET] "/pages/testimonials"). Заўсёды ўважліва глядзіце на памылкі - яны нясуць вельмі шмат карыснай інфы. Зараз адразу зразумела, што трэба дадаць маршрут для кантроллера Pages:
# config/routes.rb
get 'pages/testimonials'
Але гэта яшчэ не ўсё , бо трэба стварыць action:
# app/controllers/pages_controller.rb
def testimonials
end
Зараз ўсё працуе!
Давайце паглядзім, як працуе наша прыкладанне у кантэксце MVC. Мы зараз абстрагуемся ад web-сервера і middleware, нас цікавіць толькі праца нашага прыкладання. Паглядзіце на схему:
Што адбываецца, калі мы робім запыт на URL /pages/testimonials ? Rails роўтэр апрацоўвае URL нашага запыта і накіроўвае да дзеяння testimonials кантроллера Pages. View візуалізуе старонку HTML. Пасля гэтага кантроллер адразу вяртае нам web-старонку. Гэта найпрасцейшы выпадак, бо няма ніякага ўзаемадзеяння з мадэлью і базай дадзеных. Але ўсё па парадку. З Rails models мы будзем разбірацца на наступных занятках. Калі разглядзець запыт да URL /, розніца будзе толькі ў тым, што кантроллер перадасць зменную @hello у action home.
Мы ўжо маем мінімальна працоўнае web-прыкладанне і ажно тры статычныя старонкі. Гэта значыць, што можна разгарнуць нашае прыкладанне на сервер. Для гэтага мы скарыстаемся цудоўным воблачным сервісам Heroku. Трэба на ім зарэгістравацца.
Я рэкамендую як мага раней прыступаць да разгортвання прыкладання, бо тады можна з самага пачатку убачыць праблемы і задачы, спецыфічныя для вашага production асяроддзя на канкрэтным серверы.
Усё што трэба, каб пачаць працу з Heroku - гэта усталяваць кліента каманднага радка і крыху падрыхтаваць Rails application.
Абнаўляем Gemfile. Дадаем (пакуль што толькі ў групу production) gem pg для базы дадзеных Postgresql і выносім sqlite3 ў групу development. Пазней мы навучымся канфігураваць базы дадзеных і працаваць з імі. Зараз нам гэта не трэба, бо Heroku робіць гэта за нас. Таксама трэба дадаць gem rails_12factor - ён патрэбны для апрацоўкі статычных рэсурсаў.
# Gemfile
group :production do
# Use postgresql as the database for Active Record
gem 'pg'
#Heroku integration
gem 'rails_12factor'
end
group :development do
gem 'sqlite3'
end
Усталёваем гемы з флагам without production (на лакальнай машыне яны нам не патрэбны):
$ bundle install --without production
Калі вы раптам дадалі secrets.yml файл у ігнор, то спатрэбіцца неяк вырашаць перадачу ключоў на Heroku. Я рэкамендую карыстацца гемам heroku_secrets.
Не забудзьце зафіксаваць вашыя змянненні і адправіць на Github, перад тым як пачаць deploy.
Разгарнуць Rails прыкладанне нерэальна проста:
$ heroku login
$ heroku create course-app
$ git push heroku master
course-application у камандзе heroku create - гэта назва прыкладання. Назву пазначаць не абавязкова, Heroku калі трэба, згенеруе імя за вас.
Зусім нядаўна мы толькі стварылі наша прыкладанне, а зараз яно ўжо дасупна ў сеціве. Бачыце, як проста распрацоўваць на Rails? ;)