Основи ruby \u200b\u200bon rails. Як я вчив Ruby on Rails за три ночі
До написання цього тексту автора підштовхнуло вивчення ряду знайдених в Глобальної Мережі матеріалів, які цілком можна було б позначити однією і тією ж рубрикою / тегом: Як я вивчив Ruby (Або Ruby on Rails, PHP, JS, C ++, etc) за три дні.
Ну чи щось таке. Автору, в свою чергу, відразу ж пригадався (неконтрольовані асоціації) ряд анекдотів, об'єднаних знову-таки загальною тематикою, що полягає в оціночної характеристиці дій, які можливо виконати здуру ... російську мову могутній і неймовірно афористичний, але, на жаль, не представляється можливим процитувати ці шедеври тут; відповідно, нічого не залишається, як запропонувати увазі читача власноруч написаний варіант доки з циклу Як із задоволенням і відносно швидко навчитися працювати в Ruby on Rails.
Робочий приклад описаного в статті коду, в числі інших Rails Examples - завжди можливо знайти в тестовому блозі автора на herokuapp.com, welcome.
Методика проста, і автор зовсім не претендує тут на лаври першовідкривача: необхідно, щоб було цікаво, а результати б не змусили себе чекати. Чи не заважає таже спробувати пограти на власних слабкостях, часом адже і марнославство здатне бути на користь справі; підсумки розробки повинні бути такі, щоб їх можна було з гордістю пред'явити читачам, друзям і колегам в Мережі, задеплоів куди-небудь на Heroku або Amazon, Також - щоб можна було знову і знову до них повертатися, перебудовуючи і вдосконалюючи, форуми та StackOwerflow нам всім на допомогу. Ось я і кажу, чому б не написати, для початку, свій блог на Ruby on Rails?
Відштовхнутися пропоную від відмінною доки Getting Started with Rails або його російськомовної адаптації Rails для початківців, також Build a Blog with Ruby on Rails, також в допомогу матеріали цього блогу, посилання на які легко знаходяться в лівому сайдбарі. А далі - все, далі магія, на перших порах все розписано як по нотах, відкриваємо консоль - і вперед ... автор вважає своїм обов'язком зробити лише кілька пояснень і технічних рекомендацій, покликаних полегшити адепта пошук і набуття Світлої Сторони Сили, і не більше того. Це - тільки ваш бій, сміливіше вперед і повертайтеся з перемогою.
Отже. Step-by-step першого мануала відмінно вивірено і не викличе у вас, я сподіваюся, ніяких турбот; все, що від вас вимагається - бути уважним, скрупульозно повторюючи докладно прокоментовані кроки ... і через годину ваш перший блог вже готовий, можна перепочити і переходити до другого, кілька більш цікавого. І саме ось тут, може статися, вам знадобляться кілька побажань, до яких зараз і приступимо.
Почнемо з твердження, що ось ці методи цілком здатні (як варіант) виглядати так, як показано далі, але аж ніяк не так, як в оригіналі:
app / controllers / posts_controller.rb
# Update action updates the post with the new information def update if @ post.update_attributes (post_params) flash [: notice] \u003d "Successfully updated post!" redirect_to posts_path else flash [: alert] \u003d "Error updating post!" render: edit end end # The show action renders the individual post after retrieving the the id def show end # The destroy action removes the post permanently from the database def destroy @post \u003d Post.find (params [: id]) if @post .destroy flash [: notice] \u003d "Successfully deleted post!" redirect_to posts_path else flash [: alert] \u003d "Error updating post!" end end
А втім, спробуйте і так і сяк, чому немає. Йдемо далі.
Другий блог, хоча і більш складний (додані редактор статей CKEditor і devise, Гнучке засіб для аутентифікації в rails-додатках), чомусь позбавлений в оригіналі можливості залишати коментарі. Вам доведеться власноруч заповнити цей недолік: дійте за аналогією з описом створення першого блогу, будуть потрібні лише зовсім незначні зміни: просто кажучи, замість article і articles першого блогу будуть у вас post і posts в блозі другому, ось і вся, по суті, різниця. Будьте уважні, і все вийде.
Recaptcha до коментарів прив'язати доведеться також самостійно: так-так, це вам тут не Joomla, звикайте. Втім, титанічних зусиль не потрібно, процес підключення Recaptcha докладно описаний в статті Підключаємо Recaptcha в Rails application. Далі зовсім не зайве відрегулювати devise таким чином, щоб блог працював (хоча б на перших порах!) в режимі одного, дозволяючи численним своїм читача режим READ ONLY, іншими словами - заборонимо для початку реєстрацію нових користувачів. У Мережі досить самих різних рецептів на предмет того, як це зробити, але, на мій погляд, самий грамотний хак такого роду знаходиться в Wiki devise, в матеріалі під назвою How To: Set up devise as a single user system. А саме: створюємо новий контролер:
app / controllers / registrations_controller.rb:
Class RegistrationsController< Devise::RegistrationsController before_action:one_admin_registered?, only: [:new, :create] protected def one_admin_registered? if ((Admin.count == 1) & (admin_signed_in?)) redirect_to root_path elsif Admin.count == 1 redirect_to new_admin_session_path end end end
потім переобумовленої його в routes.rb, і це все:
#devise_for: admins devise_for: admins, controllers: (registrations: "registrations")
CKEDITOR.editorConfig \u003d function (config) (// config.enterMode \u003d 2; // disabled
Completely config.enterMode \u003d CKEDITOR.ENTER_BR // pressing the ENTER KEY input
config.shiftEnterMode \u003d CKEDITOR.ENTER_P; // pressing the SHIFT + ENTER KEYS input
Config.autoParagraph \u003d false; // stops automatic insertion of
On focus);
Мабуть, для початку це дійсно все ... чорт, найголовніше я мало не забув. Якщо деплоіть свій новий блог збираєтеся на Heroku - додайте ці три рядки в
config / application.rb
Config.assets.precompile + \u003d Ckeditor.assets config.assets.precompile + \u003d% w (ckeditor / *) config.autoload_paths + \u003d% W (# (config.root) / app / models / ckeditor)
інакше CKEditor відмовиться у вас працювати на новому місці.
У цій статті я хочу розповісти, як створити просте додаток, що працює з базою даних MySQL в середовищі Ruby on Rails 3. Можна розглядати цей матеріал, як покрокове керівництво для початківців програмістів Rails.
Отже, для роботи нам необхідна встановлені рейки і rubygems. З останніми у мене вчора була проблема, тому довелося видалити пакет rubygems1.8 не зрозуміло як опинився в системі і поставити rubygems1.9 Нагадаю, що розробляю я на Ubuntu, хоча для Windows команди консолі Rails думаю будуть тими ж. Як середовище розробки використовую NetBeans з плагіном для Ruby on Rails. Про установку непогано написано в мого колеги.
Перевірка посилань
Необхідно переконатися, що каталог / usr / bin містить символічні посилання rails, rake, ruby, bundler на файли з каталогу / usr / local / ruby \u200b\u200b/ bin. Дл перегляду посилань використовуйте команду:
в залежності від того, що хочете відфільтрувати.
створюємо додаток
Я створив спеціальний каталог для своїх ruby-додатків.
mkdir / home / andrey / ruby
cd /home.andrey/ruby
У рейок є багато консольних утиліт, які сильно полегшують роботу, особливо по прототіпірованію. Для створення програми, що використовує в якості бази mysql виконаємо команду:
app - це назва нашого нового додатка. Після виконання команди ми побачимо, як rails зробив нам каркас майбутнього програми.
[Email protected]: ~ / Ruby # rails new app -d mysql
create
create README
create Rakefile
create config.ru
create .gitignore
create Gemfile
create app
create app / controllers / application_controller.rb
create app / helpers / application_helper.rb
create app / mailers
create app / models
create app / views / layouts / application.html.erb
create config
create config / routes.rb
create config / application.rb
create config / environment.rb
create config / environments
create config / environments / development.rb
create config / environments / production.rb
create config / environments / test.rb
create config / initializers
create config / initializers / backtrace_silencers.rb
create config / initializers / inflections.rb
create config / initializers / mime_types.rb
create config / initializers / secret_token.rb
create config / initializers / session_store.rb
create config / locales
create config / locales / en.yml
create config / boot.rb
create config / database.yml
create db
create db / seeds.rb
create doc
create doc / README_FOR_APP
create lib
create lib / tasks
create lib / tasks / .gitkeep
create log
create log / server.log
create log / production.log
create log / development.log
create log / test.log
create public
create public / 404.html
create public / 422.html
create public / 500.html
create public / favicon.ico
create public / index.html
create public / robots.txt
create public / images
create public / images / rails.png
create public / stylesheets
create public / stylesheets / .gitkeep
create public / javascripts
create public / javascripts / application.js
create public / javascripts / controls.js
create public / javascripts / dragdrop.js
create public / javascripts / effects.js
create public / javascripts / prototype.js
create public / javascripts / rails.js
create script
create script / rails
create test
create test / fixtures
create test / functional
create test / integration
create test / performance / browsing_test.rb
create test / test_helper.rb
create test / unit
create tmp
create tmp / sessions
create tmp / sockets
create tmp / cache
create tmp / pids
create vendor / plugins
create vendor / plugins / .gitkeep
Заходимо в папку з ним і встановлюємо необхідні геми. Геми - це спільні бібліотеки, необхідні для проекту (аналог PHP'шних PECL і PEAR).
Після цього, в консолі буде щось на зразок цього:
[Email protected]: ~ / Ruby / app\u003e sudo bundle install
Using rake (0.8.7)
Using abstract (1.0.0)
Using activesupport (3.0.0)
Using builder (2.1.2)
Using i18n (0.4.2)
Using activemodel (3.0.0)
Using erubis (2.6.6)
Using rack (1.2.1)
Using rack-mount (0.6.13)
Using rack-test (0.5.6)
Using tzinfo (0.3.23)
Using actionpack (3.0.0)
Using mime-types (1.16)
Using polyglot (0.3.1)
Using treetop (1.4.8)
Using mail (2.2.9)
Using actionmailer (3.0.0)
Using arel (1.0.1)
Using activerecord (3.0.0)
Using activeresource (3.0.0)
Using bundler (1.0.3)
Using mysql2 (0.2.6)
Using thor (0.14.4)
Using railties (3.0.0)
Using rails (3.0.0)
Your bundle is complete! Use `bundle show` to see where a bundled gem is installed.
Це означає, що всі геми встановлені і підключені. Якщо чогось не вистачає, то bundle сам завантажить їх з rubygems і встановить. Ось цього мені довгий час не вистачало в php, по суті виходить установник проекту. Список залежних гемов знаходиться в файлі Gemfile в корені проекту.
конфігурація
Тепер треба укаать реквізити доступу до БД нашого проекту. Відкриваємо проект в NetBeans: New Project -\u003e Ruby -\u003e Ruby on Rails application with existing source. Вказуємо шлях, в моєму випадку це буде (/ home / andrey / ruby \u200b\u200b/ app) і назва проекту (app). Як Ruby Platform вибираємо встановлену в системі, а не вбудовану в NetBeans. Натискаємо Finish і проект створився. Відкриваємо псевдо-папку Configuration і файл database.yml. Тут треба вказати логін і пароль для доступу до бази, бажано відразу для всіх трьох середовищ (development, test, production). Оточення - це середовище в якій буде запускатися наш додаток,
- development - комп'ютер розробника,
- production - сервер промислової експлуатації,
- test - робота в режимі тестування на сервері безперервної інтеграції або комп'ютері тестувальника.
rails generate model User name: string hashed_password: string salt: string
Відразу видно, чого нагенеріл нам Rails:
invoke active_record
create db / migrate / 20101107054200_create_users.rb
create app / models / user.rb
invoke test_unit
create test / unit / user_test.rb
create test / fixtures / users.yml
Дуже добре, тепер нам треба створити базу даних. Виконуємо для цього:
[Email protected]: ~ / Ruby / app $ rake db: create
(In / home / andrey / ruby \u200b\u200b/ app)
[Email protected]: ~ / Ruby / app $ rake db: migrate
(In / home / andrey / ruby \u200b\u200b/ app)
\u003d\u003d CreateUsers: migrating \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d
- create_table (: users)
-\u003e 0.0061s
\u003d\u003d CreateUsers: migrated (0.0063s) \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d
Консоль виводить додані дані. Дивимося в phpmyadmin і бачимо нові бази app_development і app_test, а також таблиці в них. Тепер настала черга додати реальні дані. Для цього запускаємо консоль rails
Консоль - це не просто консоль, а консоль IRB в контексті вашого застосування. Як приклад створимо двох користувачів:
[Email protected]: ~ / Ruby / app $ rails console
Loading development environment (Rails 3.0.0)
irb (main): 001: 0\u003e user1 \u003d User.new
=> #
irb (main): 002: 0\u003e user1.name \u003d «andrey»
\u003d\u003e «Andrey»
irb (main): 003: 0\u003e user1.save
\u003d\u003e True
irb (main): 004: 0\u003e user2 \u003d User.new
=> #
irb (main): 005: 0\u003e user2.name \u003d «vasiliy»
\u003d\u003e «Vasiliy»
irb (main): 006: 0\u003e user2.save
\u003d\u003e Trueirb (main): 007 0\u003e exit
[Email protected]: ~ / Ruby / app $
Подивимося в базу, і дійсно у нас з'явилися два користувача. Хочеться відзначити, що Rails сам додав стовпці первинного ключа і поля created_at (дата створення) і updated_at (дата зміни) моделі.
Модель у нас є, дані теж. Пора запустити наш додаток.
[Email protected]: ~ / Ruby / app $ rails server
\u003d\u003e Booting WEBrick
\u003d\u003e Rails 3.0.0 application starting in development on http://0.0.0.0:3000
\u003d\u003e Call with -d to detach
\u003d\u003e Ctrl-C to shutdown server
INFO WEBrick 1.3.1
INFO ruby \u200b\u200b1.9.2 (2010-08-18)
INFO WEBrick :: HTTPServer # start: pid \u003d 4193 port \u003d 3000
Додаток запущено, відкриваємо браузер за адресою і бачимо тестову сторінку.
Відмінно, додаток працює. Але воно показує звичайну HTML-сторінку з папки /public/index.html. А ми хочемо динамічну. Відкриваємо друге вікно консолі (тому що в першому у нас запущений вер-сервер рубай - WebRick), заходимо в папку з проектом і набираємо там наступну команду:
[Email protected]: ~ / Ruby / app $ rails generate controller index index
create app / controllers / index_controller.rb
route get «index / index»
invoke erb
create app / views / index
create app / views / index / index.html.erb
invoke test_unit
create test / functional / index_controller_test.rb
invoke helper
create app / helpers / index_helper.rb
invoke test_unit
create test / unit / helpers / index_helper_test.rb
[Email protected]: ~ / Ruby / app $
Цим ми створили коонтроллер Index, в ньому дію Index і вид цієї дії index.html.erb Робимо Refresh (F5) в NetBeans і дивимося наші файли. Чудово. Тепер нам треба якось переспрямувати маршрут для головної сторінки на створене нам дію контролера. Відкриваємо файл маршрутів (Configuration / routes.rb) і раскомментіруем там наступний рядок:
# You can have the root of your site routed with «root»
# Just remember to delete public / index.html.
root: to \u003d\u003e «welcome # index»
Тільки замість welcome пишемо теж index. Ну звик я по Zend Framework'у, що контролер і дію по-замовчуванню називаються index Чи не забиавем видалити (або перейменувати) файл public / index.html).
root: to \u003d\u003e «index # index»
Оновлюємо сторінку в браузері, і бачимо, що тепер відображається наш вид.
Index # index
Відмінно. Тепер можна кодувати Заходимо в наш новостворений контролер (Controllers -\u003e index_controller.rb) і пишемо там такий текст дії:
class IndexController< ApplicationController
def index
@users \u003d User.find (: all)
end
end
Тепе відкриваємо вид Views / index / index.html.erb і пишемо там такий код:
Index # index
Find me in app / views / index / index.html.erb
<% for user in @users -%>
<%=user.name%>
<% end %>
Цим, ми говоримо Rails пройтися по масиву користувачів і відобразити їх імена. Оновлюємо сторінку і бачимо список користувачів внизу.
Index # index
Find me in app / views / index / index.html.erb
andrey
vasiliy
Відмінно! Додаток створено!
Дякуємо!
Якщо вам допомогла стаття, або ви хочете підтримати мої дослідження і блог - ось кращий спосіб зробити це:Сьогодні в інтернетах я знайшов історію про те, як хтось Джеймс Фенд навчався Ruby on Rails протягом 12 тижнів. Нижче ви можете прочитати відносно точний переклад цієї історії, і, сподіваюся, надихнутися на вивчення цього прекрасного фреймворка (і прекрасного мови).
Перш ніж почати, я хотів би представити Джоша Кріуса (http://joshcrews.com) і подякувати йому за те, що переконав мене почати вивчати Ruby on Rails; без нього, його допомоги і без годинника, який він витратив на те, щоб бути моїм наставником, я не писав би це сьогодні. Дякуємо.
23 січня я запустив ідею своєї мрії, Freelancify.com. Рівно 12 тижнів тому я був технічним підприємцем (tech entrepreneur), який витрачав тисячі доларів, щоб створити пристойний MVP (мінімально життєздатний продукт), тому що мені бракувало знань. Однією з причин (як я тоді думав) було те, що навчання було для мене занадто складним або зайняло б надто багато часу. Я думав (як і багато інших), що програмісти (і деякі дійсно) народжуються з набором чарівних навичок у вирішенні проблем та математики, які роблять їх геніями програмування. І саме 12 тижнів тому я прийняв краще рішення за довгий, по-справжньому довгий час. Більше жодна з моїх ідей не залишиться не більше ніж ідеєю. Тепер у мене є можливість запускати робочі версії, витрачаючи гроші лише на хостинг і докладаючи певних зусиль. На сьогоднішній день цей набір навичок - це приблизно як пригнати купу тракторів за часів каліфорнійської золотої лихоманки, поки всі інші використовують прості лопати. Я пропоную кожному навчитися писати код. Тут я хотів би додати уточнення: раніше, назвав пост "Як я вивчив Rails за 8 тижнів", проте, якщо бути точним, то з огляду на дату запуску, виходить 12 тижнів. Однак за 8 тижнів я відчув, що знаю достатньо, а наступні чотири тижні були витрачені в більшій мірі на те, щоб змусити отримані знання працювати, а не на навчання.
Які навички я мав перед тим, як почав вивчати Rails?
Я був веб-дизайнером, що володіє знаннями в HTML і CSS, і, в основному, фокусувався на дизайні UI і UX. Найскладніше, що я робив з реальним кодом (не рахуючи HTML) - це можливість налаштовувати Wordpress. Одним словом, я абсолютно не мав уявлення ні про те, що таке MVC-фреймворк, ні про те, як в цілому працюють бази даних. Дизайн, макет і HTML для Freelancify були створені мною за два тижні в червні 2011-го.
Чому я прийняв рішення вчитися?
Повертаючись в червень 2011-го, коли макет був готовий, я почав пошуки кодера, який зробив би макет функціонуючим. Макет був практично готовий: у мене були текстові поля, що випадають меню, форми, кнопки, посилання, що ведуть куди необхідно, і так далі. Знайшов розробника, і, якщо в двох словах, то хлопець мені не підійшов. Я залишився з купою боргів і навіть не близьким до завершення продуктом. Тоді я зв'язався з Джошем Кріусом (з ним я познайомився на зустрічі, присвяченій Ruby on Rails, яку він організував в Нешвіллі), і зустрівся з ним, щоб зрозуміти, чи можна зробити хоч щось з того, що у мене залишилося від розробника . На жаль, лагодження та доопрацювання коду зайняла б не менше часу, ніж розробка з нуля грамотним програмістом. Я впав духом, розуміючи, що не зможу дозволити собі знову витрачати тисячі доларів на розробку з нуля. І тоді Джош сказав ... " Чому б тобі просто не навчитися поводитися з Ruby on Rails, цей проект був би прекрасним способом" і потім " Я можу навіть зустрічатися з тобою двічі в тиждень і допомагати тобі в навчанні". Я витратив цілу ніч на роздуми. Моїми варіантами було: знайти комфортну роботу і оплатити рахунки АБО ризикнути всім, щоб навчитися Rails і, врешті-решт, ласувати кращим раменом, який тільки готують в Італії. Я вирішив. Подзвонив Джошу на наступний ранок. Я поставив все. Я виділив гроші з решти заощаджень і розділив їх на три місяці (для неодруженого хлопця, який живе на самоті і без дітей однієї тисячі доларів на місяць цілком достатньо). Час братися до роботи, тепер я учень на повному робочому дні. Тримаю в голові: пошук в Google, Stackoverflow, IRC #RubyOnRails і співтовариство Rails будуть прикривати мене, коли я застрягну, впевнений, що їх буде достатньо.
Мої наступні три місяці - Місія: Отримати MVP, отримати досить, щоб працювати, але не "отстойно-достатньо", щоб залишити жахливе перше враження.
Тижня 1 - 3
Це була, мабуть, найскладніша крива навчання, але я НЕ здавався.
Стіни створені для людей, які, насправді, не хочуть їх залишати.
Установка робочого оточення Rails для повного новачка може виявитися неймовірно дратує. Підказка # 1: запозичень Mac. Підказка # 2: використовуйте Homebrew, RVM, Git і Heroku (насправді це все, що вам потрібно, щоб почати). Я витратив пару днів на установку, потім все видалив і знову встановив. Досить повторити кілька разів, і ви звикнете до використання командного рядка терміналу (консолі) і зрозумієте, чому речі працюють так, як вони працюють. Потім, перша річ, якої я зайнявся, були уроки TryRuby, Rails for Zombies і Rails Tutorial Майкла Хартла. Не турбуйтеся про те, щоб на 120% зрозуміти матеріал, цього не станеться, поки ви не почнете по-справжньому вчитися. Я закінчив Rails Tutorial і створив це схоже на Twitter додаток приблизно за тиждень, не зовсім розуміючи, що я зробив. Пізніше, у міру просування, я став розуміти, що все починає знаходити сенс.
Тижні 3 - 6
З Twitter-додатком, створеним за допомогою Rails Tutorial, я знайшов деяку впевненість. Керівництво не зробило мене розробником, але тепер я знаю загальні кроки в створенні додатків, з створення самого додатка, і до установки його на Heroku. Все, що було між тим часом залишалося розмитим. Як мені тепер ПО-СПРАВЖНЬОМУ почати вчитися? Працюючи над реальним проектом, який щось для мене значить. Джош і я вирішили, що мені варто вільно попрацювати над Freelancify і подивитися, що я зможу зробити. Першим, що я зробив, було перенесення всього HTML з каркаса і організація його в файли видів (views) і парціалов (partials). Я створив (scaffolded) шаблонні платформи для користувачів (Users) і Проектів (Projects). Потім я почав вивчати мій перший реальний гем Devise. Потім, можливість мати відносини, наприклад кожен Користувач матиме портфоліо. Але користувачі можуть мати безліч портфоліо, в той час як кожне портфоліо може належати лише одному Користувачеві. Коли ви зрозумієте, як працюють стосунки між моделями і як викликати / відображати речі, які належать чогось ще, життя стане набагато простіше. Якщо в якійсь частині ви застрягли і не можете зрушити з місця, пропустіть її, велика ймовірність того, що поки ви розробляєте іншу можливість, ви так само зрозумієте, як реалізувати і те, що ви пропустили.
Тижня 6 - 9
Крок за кроком, я продовжував вчитися, копіюючи і повторюючи. Я міг змушувати якісь речі працювати, а потім - бац - і я встромляли в стіну і абсолютно не уявляв, що ж робити далі. Заходячи на Stackoverflow, IRC-чат #RubyOnRails, RailsCasts або смикаючи Джоша, в кінці кінців, я розумів, як діяти. Робіть те ж саме знову і знову, і ви навчитеся всьому досить швидко. Витрачати дратівливі годинник, тестуючи чийсь відповідь зі Stackoverflow, щоб зрозуміти, що він не працює - це, насправді, корисно. Ви розумієте, чого не слід робити. І коли ви знайдете відповідь, ви почнете розуміти, ЧОМУ останнє не працювало. Приблизно в цей час я почав усвідомлювати, наскільки велика картина речей, і по-справжньому розуміти, ЧОМУ все працює саме так, як працює. Я відчував себе ідіотом, повертався назад і рефактору код, який написав раніше, роблячи його більш ефективним. І в якийсь момент я досяг стадії, коли все почало ставати на свої місця.
Тижня 9 - 12
Я був в режимі неймовірною енергійності, допрацьовує Freelancify до стадії запуску. На цій стадії я відчував себе так, немов лечу, втілюючи функції в життя. Останній тиждень була витрачена на налагодження різних багів і ляпів. Цього понеділка я запустив сайт. Але я як і раніше далекий від завершення навчання ... Ось так. Я опустив (в ім'я стислості поста) дрібні деталі і технічні моменти. Тим не менш, не соромтеся задавати питання в коментарях, я виразно спробую відповісти. Джеймс Фенд.
P.S. - Не дивлячись на те, що мені сильно допомогла допомогу наставника, з яким я міг зустрічатися, ви безумовно можете вивчити Rails і без нього. Або ж спробуйте знайти собі таку людину, багато Rails-розробники люблять вносити свій внесок до спільноти. Пошукайте локальні конференції та зустрічі.
Цією записи вже більше двох років (опублікована 27 січня 2012-го року), але вона, тим не менш, не втратила своєї актуальності. Джеймс Фенд за цей час встиг продати Freelancify і вкластися в новий стартап, запис про це він залишив 27 лютого 2013. Я вважаю, що ця стаття - прекрасний приклад того, як людина може йти до поставленої мети. Достатньо лише почати. :)
Це керівництво розкриває установку і запуск Ruby on Rails.
Після його прочитання, ви дізнаєтеся:
- Як встановити Rails, створити новий додаток на Rails і приєднати ваше додаток до бази даних.
- Загальну структуру програми на Rails.
- Основні принципи MVC (Model, View Controller - «Модель-вистава-контролер») і дизайну, заснованого на RESTful.
- Як швидко генерувати початковий код програми на Rails.
Допущення в цьому керівництві
Це керівництво розраховане на новачків, які хочуть запустити додаток на Rails з нуля. Воно не передбачає, що ви раніше працювали з Rails.
Rails - фреймворк для веб-розробки, написаний на мові програмування Ruby. Якщо у вас немає досвіду в Ruby, можливо вам буде важко відразу приступити до вивчення Rails. Є кілька хороших англомовних ресурсів, присвячених вивченню Ruby, наприклад:
Звертайте увагу, що деякі ресурси, хоча все ще чудові, але все ж покривають старі версії Ruby, такі як 1.6, і особливо 1.8, і не включає деякі елементи синтаксису, які ви побачите в повсякденному розробці на Rails.
Що таке Rails?
Rails - фреймворк для веб-розробки, написаний на мові програмування Ruby. Він розроблений, щоб зробити програмування веб-додатків простіше, так як використовує ряд припущень про те, що потрібно кожному розробнику для створення нового проекту. Він дозволяє вам писати менше коду в процесі програмування, в порівнянні з іншими мовами і фреймворками. Професійні розробники на Rails також відзначають, що з ним розробка веб-додатків більш забавна \u003d)
Rails - свавільний програмний продукт. Він робить припущення, що є "кращий" спосіб щось зробити, і він так розроблений, що стимулює цей спосіб - а в деяких випадках навіть перешкоджає альтернативам. Якщо вивчіть "The Rails Way", то, можливо, відкриєте в собі значне збільшення продуктивності. Якщо будете наполягати і переносити старі звички з інших мов в розробку на Rails, і спробуєте використовувати шаблони, вивчені десь ще, ваш досвід розробки буде менш щасливим.
Філософія Rails включає два важливих провідних принципів:
- Don "t Repeat Yourself: DRY - це принцип розробки ПО, який говорить, що "Кожен шматочок інформації повинен мати єдине, неізбиточное, авторитетне уявлення в системі". Не пишіть одну і ту ж інформацію знову і знову, код буде легше підтримувати, і він буде більш розширюваним і менш помилковим.
- Convention Over Configuration: у Rails є думки про найкращі способи робити безліч речей в веб-додатку, і за замовчуванням виставлені ці угоди, замість того, щоб змушувати вас по дрібницях правити численні конфігураційні файли.
Створення нового проекту Rails
Кращий спосіб використання цього керівництва - проходити його крок за кроком. Всі кроки істотні для запуску службовця прикладом додатки, крім них більше не потрібно будь-якого додаткового коду або кроків.
Слідуючи цьому керівництву, ви створите проект Rails з назвою blog, дуже простий веб-блог. Перш ніж почнемо створювати додаток, потрібно переконатися, що сам Rails встановлений.
Перелічені нижче приклади використовують $ для позначення рядка введення терміналу в UNIX-подібних операційних системах, хоча він може бути налаштований по-іншому. Якщо використовується Windows, рядок буде виглядати на зразок c: \\ source_code\u003e
3.1. установка Rails
Перед установкою Rails необхідно перевірити, щоб у вашій системі були встановлені необхідні попередні залежності. До них відносяться Ruby і SQLite3.
Відкрийте додатки для командного рядка. На macOS відкрийте Terminal.app, на Windows виберіть "Run" в меню Start і напишіть "cmd.exe". Будь-які команди, що починаються зі знака долара $ повинні бути запущені в командному рядку. Переконайтеся, що у вас встановлена \u200b\u200bпоточна версія Ruby:
$ Ruby -v ruby \u200b\u200b2.5.0
Rails вимагає, щоб був встановлений Ruby версії 2.5.0 або новіший. Якщо номер версії менше цієї, потрібно буде встановити нову копію Ruby.
Щоб швидко встановити Ruby і Ruby on Rails в системі, користувачі Windows можуть використовувати Rails Installer. Додаткові методи установки для більшості операційних систем можна побачити на ruby-lang.org.
Якщо працюєте в Windows, необхідно встановити Ruby Installer Development Kit.
Вам також знадобиться установка бази даних SQLite3.
Багато популярних UNIX-подібні ОС поставляються з прийнятною версією SQLite3. На Windows, якщо ви встановлювали Rails за допомогою Rails Installer, у вас вже встановлений SQLite. Інші користувачі можуть звернутися до інструкцій по установці на сайті SQLite3. Перевірте, що він правильно встановлений і міститься в вашому PATH:
$ Sqlite3 --version
Програма повинна повідомити свою версію.
Для установки Rails використовуйте команду gem install, представлену RubyGems:
$ Gem install rails
Щоб перевірити, що все встановлено правильно, потрібно виконати наступне:
$ Rails --version
Якщо виводиться щось на кшталт "Rails 6.0.0", можна продовжувати.
3.2. Створення програми Blog
Rails поставляється з рядом скриптів, названих генераторами, розроблених для полегшення життя розробника, створюючи все, що необхідно для початку роботи над певним завданням. Одним з них є генератор нової програми, що надає вам основу програми Rails, таким чином, вам не потрібно писати його самим.
Для використання цього генератора, відкрийте термінал, увійдіть в папку, в якій у вас є права на створення файлів і напишіть:
$ Rails new blog
Це створить додаток на Rails з ім'ям Blog в директорії blog і встановить геми, залежно від яких згадані в Gemfile при використанні bundle install.
При використанні Windows Subsystem for Linux, є деякі обмеження на повідомлення файлової системи, які означають, що слід відключити геми spring і listen, що можна зробити, запустивши rails new blog --skip-spring --skip-listen.
Можна подивитися всі можливі опції командного рядка, які приймає билдер додатки на Rails, запустивши rails new -h.
Після того, як ви створили додаток blog, перейдіть в його папку:
В директорії blog є кілька розсилаються файлів і папок, які задають структуру програми на Rails. Велика частина роботи в цьому самовчителі відбуватиметься в папці app, але зараз пробіжить по функціям кожної папки, які створює Rails в новому додатку за замовчуванням:
| Файл / Папка | призначення |
|---|---|
| app / | Містить контролери, моделі, вьюха, хелпери, розсильників, канали, завдання і Ассет вашого застосування. Ми розглянемо цю папку докладніше далі. |
| bin / | Містить Rails скрипти які стартують ваше додаток, також директорія може містити інші скрипти які ви використовуєте для настройки, поновлення, деплоя або запуску. |
| config / | Конфігурації маршрутів, бази даних вашого застосування, і т.д. Більш детально це розкрито в Конфигурирование додатків на Rails |
| config.ru | Конфігурація Rack для серверів, заснованих на Rack, використовуваних для запуску програми. Детальніше про Rack дивіться на сайті Rack. |
| db / | Містить поточну схему вашої бази даних, а також міграції бази даних. |
| Gemfile Gemfile.lock |
Ці файли дозволяють вказати, які залежно від гемов потрібні для вашого застосування на Rails. Ці файли використовуються гемом Bundler. Детальніше про Bundler дивіться на сайті Bundler. |
| lib / | Модулі для вашого застосування. |
| log / | Лог-файли програми. |
| package.json | Цей файл дозволяє вказати, які залежно npm необхідні для застосування Rails. Цей файл використовується Yarn. Детальніше про Yarn дивіться на сайті Yarn. |
| public / | Єдина папка, яка доступна ззовні як є. Містить статичні файли і скомпільовані Ассет. |
| Rakefile | Цей файл знаходить і завантажує завдання, які можуть бути запущені в командному рядку. Певна завдання доступна у всіх компонентах Rails. Замість зміни Rakefile, можна додати свої власні завдання, додавши файли в директорію lib / tasks додатки. |
| README.md | Це вступний мануал для вашого застосування. Його слід відредагувати, щоб розповісти іншим, що ваш додаток робить, як його налаштувати, і т.п. |
| storage / | Файли Active Storage для сервісу Disk. Це розкривається в керівництві Огляд Active Storage. |
| test / | Юніт-тести, фікстура та інший апарат тестування. Це розкривається в керівництві Тестування додатків на Rails |
| tmp / | Тимчасові файли (такі як файли кеша і pid) |
| vendor / | Місце для коду сторонніх розробників. У типовому додатку на Rails включає зовнішні геми. |
| .gitignore | Цей файл повідомляє git, які файли (явно або за шаблоном) йому слід ігнорувати. Детальніше про ігнорування файлів дивіться GitHub - Ignoring files. |
| .ruby-version | Цей файл містить дефолтну версію Ruby. |
Hello, Rails!
Для початку, давайте виведемо на екран будь-якої текст. Для цього потрібен запущений сервер вашого застосування на Rails.
4.1. Запуск веб-сервера
Фактично у вас вже є функціональне додаток на Rails. Щоб переконатися, потрібно запустити веб-сервер на вашій машині. Це можна здійснити, запустивши таку команду з директорії blog:
Якщо ви використовуєте Windows, ви повинні передавати скрипти з папки bin безпосередньо в інтерпретатор Ruby, тобто ruby \u200b\u200bbin \\ rails server.
Стиснення Ассет JavaScript вимагає середовища виконання JavaScript у вашій системі, і його відсутність призведе до помилки execjs під час стиснення Ассет. Зазвичай macOS і Windows поставляються зі встановленою середовищем виконання JavaScript. therubyrhino - рекомендована Виконавча для користувачів JRuby, вона додається в Gemfile, якщо додаток генерується під JRuby. Можна дізнатися все про підтримуваних середовищах виконання в ExecJS
Це запустить Puma, веб-сервер, що поширюється з Rails за замовчуванням. Щоб побачити додаток в дії, відкрийте вікно браузера і пройдіть за адресою http: // localhost 3000. Ви повинні побачити дефолтну інформаційну сторінку Rails:
Для зупинки веб-сервера натисніть Ctrl + C в терміналі, де він запущений. Щоб переконатися в тому, що сервер був зупинений, ви повинні знову побачити курсор командного рядка. Для більшості UNIX-подібних систем, включаючи macOS, це буде знак долара $. У режимі development, Rails в основному не вимагає зупинки сервера; всі зміни, які Ви робите в файлах, автоматично підхоплюються сервером.
Сторінка "Welcome Aboard" це своєрідний тест для нової програми на Rails: вона показує, що ваші програми налаштовані досить правильно для відображення сторінки.
4.2. Скажіть "привіт", Рейки
Щоб Rails сказав "Привіт", потрібно створити, як мінімум, контролер і вьюха (Подання).
Призначенням контролера є отримання певних запитів до додатка. Роутінг вирішує, який контролер отримає якісь запити. Часто є більше одного маршруту до кожного контролера, і різні маршрути можуть бути оброблені різними екшн. Призначенням кожного екшна є збір інформації для надання її у вьюха.
Призначенням вьюха є відображення цієї інформації в зрозумілому людині форматі. Необхідно відзначити істотну різницю, що місцем, в якому збирається інформація, є контролер, А не вьюха. Вьюха повинна тільки відображати цю інформацію. За замовчуванням шаблони вьюха пишуться на мові, названому eRuby (Embedded Ruby), який конвертується циклом запитів в Rails до відправки користувачеві.
Для створення нового контролера, потрібно запустити генератор "controller" і сказати йому, що ви хочете контролер з ім'ям "Welcome" з екшном на ім'я "index", ось так:
$ Rails generate controller Welcome index
Rails створить кілька файлів і маршрут.
Create app / controllers / welcome_controller.rb route get "welcome / index" invoke erb create app / views / welcome create app / views / welcome / index.html.erb invoke test_unit create test / controllers / welcome_controller_test.rb invoke helper create app / helpers / welcome_helper.rb invoke test_unit invoke assets invoke scss create app / assets / stylesheets / welcome.scss
Найбільш важливими з них є, зрозуміло, контролер, розташований в app / controllers / welcome_controller.rb, і вьюха, розташована в app / views / welcome / index.html.erb.
Відкрийте файл app / views / welcome / index.html.erb в текстовому редакторі. Видаліть весь існуючий в файлі код і замініть його на наступну сходинку коду:
Якщо ще раз відправити форму, ви побачите щось на кшталт такого:
Тепер цей стрілялки відображає параметри для статті, що прийшли з форми. Однак, це все ще марно. Так, ви бачите параметри, але по суті нічого не робите з ними.
5.4. Створення моделі Article
Моделі в Rails використовують ім'я в однині, а їх відповідна таблиця в базі даних - ім'я у множині. Rails надає генератор для створення моделей, яким користуються більшість розробників на Rails для створення нових моделей. Для створення нової моделі, запустіть цю команду в своєму терміналі:
$ Rails generate model Article title: string text: text
За допомогою цієї команди ми повідомляємо Rails, що хочемо модель Article з атрибутом title строкового типу і атрибутом text текстового типу. Ці атрибути автоматично додадуться в таблицю articles і прив'яжуться до моделі Article.
Rails у відповідь створить ряд файлів. Зараз нам цікаві тільки app / models / article.rb і db / migrate / 20140120191729_create_articles.rb (у вас ім'я може трохи відрізнятися). Останній відповідальний за створення структури бази даних, тому ми і розглянемо його далі.
Active Record досить кмітливий, щоб автоматично зв'язати імена стовпців з атрибутами моделі, що означає, що всередині моделей Rails не потрібно оголошувати атрибути, Active Record зробить це автоматично.
5.5. запуск міграції
Як ви вже бачили, rails generate model створив файл міграції бази даних в директорії db / migrate. Міграції - це клас Ruby, розроблений для того, щоб було просто створювати і модифікувати таблиці бази даних. Rails використовує команди rake для запуску міграцій, і можлива відміна міграції після того, як вона була застосована до вашої базі даних. Файл міграції включає тимчасову мітку, щоб бути впевненим, що вони виконуються в тій послідовності, в якій вони створювалися.
Якщо Ви заглянете в файл db / migrate / YYYYMMDDHHMMSS_create_articles.rb (пам'ятаєте, у вас файл має трохи інше ім'я), ось що там виявите:
Class CreateArticles< ActiveRecord::Migration def change create_table:articles do |t| t.string:title t.text:text t.timestamps end end end
Ця міграція створює метод change, що викликається при запуску цієї міграції. Екшени, певне в цій міграції, також є оборотним, що означає, що Rails знає, як скасувати зміни, зроблені цією міграцією, в разі, якщо ви вирішите їх скасувати пізніше. Коли ви запустите цю міграцію, вона створить таблицю articles зі строковим стовпцем і текстовим стовпцем. Вона також створить два поля тимчасових міток для відстеження часу створення та оновлення статті.
Зараз нам потрібно використовувати команду rails, щоб запустити міграцію:
$ Rails db: migrate
Rails виконає цю команду міграції і повідомить, що він створив таблицю Articles.
CreateArticles: migrating \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d - create_table (: articles) -\u003e 0.0019s \u003d\u003d CreateArticles: migrated (0.0020s) \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d
Так як ви працюєте за замовчуванням в середовищі development, ця команда буде застосована до бази даних, визначеної в розділі development вашого файлу config / database.yml. Якщо хочете виконати міграції в іншому середовищі, наприклад в production, слід явно передати її при виклику команди: rails db: migrate RAILS_ENV \u003d production.
5.6. Збереження даних в контролері
Повернемося до ArticlesController, нам потрібно змінити стрілялки create, щоб використовувати нову модель Article для збереження даних в базі даних. Відкрийте app / controllers / articles_controller.rb і змініть стрілялки create наступним чином:
Def create @article \u003d Article.new (params [: article]) @ article.save redirect_to @article end
Ось що тут відбувається: кожна модель Rails може бути инициализирована за допомогою відповідних атрибутів, які будуть автоматично прив'язані до відповідних стовпцях бази даних. У першому рядку ми якраз це і робимо (пам'ятаєте, що params [: article] містить цікаві для нас атрибути). Потім @ article.save відповідальний за збереження моделі в базу даних. Нарешті, ми перенаправляємо користувача на стрілялки show, який ми визначимо пізніше.
Ви, можливо, задається питанням, чому A в Article.new заголовна, хоча всі інші посилання на статті в цьому керівництві використовують рядкове написання. У цьому контексті ми посилаємося на клас по імені Article, який визначений в app / models / article.rb. Імена класів в Ruby повинні починатися з великої літери.
Тепер, коли є валідації, при виклику @ article.save на невалидность статті, буде повернуто false. Якщо знову відкрити app / controllers / articles_controller.rb, ви побачите, що ми не перевіряємо результат виклику @ article.save в екшені create. Якщо в цій ситуації @ article.save не вдасться, нам потрібно знову показати форму користувачеві. Для цього замініть екшени new і create в app / controllers / articles_controller.rb на ці:
Def new @article \u003d Article.new end def create @article \u003d Article.new (article_params) if @ article.save redirect_to @article else render "new" end end private def article_params params.require (: article) .permit (: title ,: text) end
Тепер стрілялки new створює нову змінну примірника на ім'я @article, і ви побачите, навіщо це, через пару абзаців.
Відзначте, що в екшені create ми використовували render замість redirect_to, коли save повертає false. Метод render використаний, щоб об'єкт @article був переданий назад в шаблон new, коли він буде отрендеріть. Цей рендеринг виконується в рамках того ж запиту, що і відправка форми, в той час як redirect_to повідомляє браузеру виконати інший запит.
5.11. оновлення статей
Ми розкрили частину "CR" від CRUD. Тепер сфокусуємось на частини "U", оновленні (updating) статей.
Першим кроком слід додати стрілялки edit в ArticlesController, як правило між стрілялки new і create, як показано.
Def new @article \u003d Article.new end def edit @article \u003d Article.find (params [: id]) end def create @article \u003d Article.new (article_params) if @ article.save redirect_to @article else render "new" end end
Вьюха буде містити форму, схожу з тією, яку ми використовували при створенні нових статей. Створіть файл з ім'ям app / views / articles / edit.html.erb і додайте в нього наступне:
Editing article
<%= form_with(model: @article, local: true) do |form| %> <% if @article.errors.any? %><%= pluralize(@article.errors.count, "error") %>
-
<% @article.errors.full_messages.each do |msg| %>
- <%= msg %> <% end %>
<%= form.label:title %>
<%= form.text_field:title %>
<%= form.label:text %>
<%= form.text_area:text %>
<%= form.submit %>
<% end %> <%= link_to "Back", articles_path %>Зараз ми вказуємо формі на стрілялки update, який поки не визначений, але скоро ми це зробимо.
Передача об'єкта статті в метод form_with автоматично встановить URL для відправки форми відредагованою статті. Ця опція повідомляє Rails, що ми хочемо, щоб ця форма була відправлена \u200b\u200bза допомогою PATCH, методу HTTP, від якого очікується, що він використовується для поновлення ресурсів відповідно до протоколу REST.
Потім потрібно створити стрілялки update в app / controllers / articles_controller.rb. Додайте його між екшном create і методом private:
Def create @article \u003d Article.new (article_params) if @ article.save redirect_to @article else render "new" end end def update @article \u003d Article.find (params [: id]) if @ article.update (article_params) redirect_to @article else render "edit" end end private def article_params params.require (: article) .permit (: title,: text) end
Новий метод, update, використовується, коли хочете оновити запис, яка вже існує, і він приймає хеш, що містить атрибути, які ви хочете оновити. Як і раніше, якщо буде помилка оновлення статті, ми хочемо знову показати форму користувачеві.
Ми заново використовували метод article_params, який визначили раніше для екшна create.
Не обов'язково передавати всі атрибути в update. Наприклад, якщо був викликаний @ article.update (title: "A new title"), Rails оновить тільки атрибут title, залишивши всі інші атрибути недоторканими.
| Title | Text | ||
|---|---|---|---|
| <%= article.title %> | <%= article.text %> | <%= link_to "Show", article_path(article) %> | <%= link_to "Edit", edit_article_path(article) %> |
І також додамо в шаблон app / views / articles / show.html.erb, щоб посилання "Edit" також була на сторінці статті. Додайте наступне в кінці шаблону:
... <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>
І ось як виглядає наш додаток зараз:
5.12. Використання партіалов для очищення повторення у вьюха
Наша сторінка edit дуже схожа на сторінку new, фактично вони використовують один і той же код для відображення форми. Давайте приберемо це дублювання, використавши партіал вьюха. За угодою, файли партіалов починаються зі знака підкреслення.
Створіть новий файл app / views / articles / _form.html.erb наступного змісту:
<%= form_with model: @article, local: true do |form| %> <% if @article.errors.any? %>
<%= pluralize(@article.errors.count, "error") %> prohibited this article from being saved:
-
<% @article.errors.full_messages.each do |msg| %>
- <%= msg %> <% end %>
<%= form.label:title %>
<%= form.text_field:title %>
<%= form.label:text %>
<%= form.text_area:text %>
<%= form.submit %>
<% end %>Давайте зараз відновимо вьюха app / views / articles / new.html.erb, щоб використовувати цей новий партіал, переписавши її повністю:
New article
<%= render "form" %> <%= link_to "Back", articles_path %>І те ж саме для вьюха app / views / articles / edit.html.erb:
Edit article
<%= render "form" %> <%= link_to "Back", articles_path %>5.13. видалення статей
Тепер ми готові розкрити частину "D" від CRUD, видалення (deleting) з бази даних. Дотримуючись угодою REST, маршрут для видалення статей в результатах виведення rails routes наступний:
DELETE /articles/:id(.:format) articles # destroy
Метод роутінга delete повинен бути використаний для маршрутів, що знищують ресурси. Якби його залишити звичайним маршрутом get, стане можливим створювати такі зловмисні URL:
look at this cat!
Ми використовуємо метод delete для знищення ресурсів, і цей маршрут зв'язується з екшном destroy в app / controllers / articles_controller.rb, який ще не існує. Метод destroy зазвичай останній стрілялки CRUD в контролері, і подібно іншим публічним стрілялки CRUD, він повинен бути розташований перед будь-якими private або protected методами. Давайте його додамо:
Def destroy @article \u003d Article.find (params [: id]) @ article.destroy redirect_to articles_path end
Повністю ArticlesController в файлі app / controllers / articles_controller.rb повинен виглядати тепер так:
Class ArticlesController< ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new @article = Article.new end def edit @article = Article.find(params[:id]) end def create @article = Article.new(article_params) if @article.save redirect_to @article else render "new" end end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render "edit" end end def destroy @article = Article.find(params[:id]) @article.destroy redirect_to articles_path end private def article_params params.require(:article).permit(:title, :text) end end
Можна викликати destroy на об'єктах Active Record, коли ви хочете видалити їх з бази даних. Відзначте, що нам не потрібно додавати вьюха для цього екшна, так як ми перенаправляємо на стрілялки index.
Listing Articles
<%= link_to "New article", new_article_path %>| Title | Text | |||
|---|---|---|---|---|
| <%= article.title %> | <%= article.text %> | <%= link_to "Show", article_path(article) %> | <%= link_to "Edit", edit_article_path(article) %> | <%= link_to "Destroy", article_path(article), method: :delete, data: { confirm: "Are you sure?" } %> |
Тут ми використовуємо link_to іншим чином. Ми передаємо іменований маршрут як другий аргумент, і опції як інший аргумент. Опції method:: delete і data: (confirm: "Are you sure?") Використовуються як атрибути html5, тому при натисканні посилання, Rails спочатку покаже користувачеві діалог підтвердження, а потім відправить посилання за допомогою методу delete. Це виконується за допомогою файлу JavaScript rails-ujs, який автоматично включається в макет додатки (app / views / layouts / application.html.erb) при генерації додатки. Без цього файлу діалог підтвердження не буде показаний.
Наші вітання, тепер ви можете створювати, переглядати всі і окремо, оновлювати і знищувати статті.
Додаємо другу модель
Настав час додати другу модель в додаток. Друга модель буде обробляти коментарі до статей.
6.1. генеруємо модель
Ми маємо намір використовувати той же генератор, що ми використовували раніше при створенні моделі Article. Цього разу ми створимо модель Comment, що містить посилання на статтю. Запустіть наступну команду в терміналі:
$ Rails generate model Comment commenter: string body: text article: references
Ця команда генерує чотири файли:
Спочатку поглянемо на app / models / comment.rb:
Class Comment< ApplicationRecord belongs_to:article end
Це дуже схоже на модель Article, яку ми бачили раніше. Різниця в рядку belongs_to: article, яка встановлює зв'язок Active Record. Ви ознайомитеся зі зв'язками в наступному розділі керівництва.
Ключове слово (: references), використане в команді bash, це спеціальний тип даних для моделей. Він створює новий стовпець у вашій базі даних з ім'ям представленої моделі з доданим _id, який може містити числові значення. Щоб краще зрозуміти, проаналізуйте файл db / schema.rb після виконання міграції.
На додаток до моделі, Rails також зробив міграцію для створення відповідної таблиці бази даних:
Class CreateComments< ActiveRecord::Migration def change create_table:comments do |t| t.string:commenter t.text:body t.references:article, null: false, foreign_key: true t.timestamps end end end
Рядок t.references створює числовий стовпець з ім'ям article_id, індекс для нього, і обмеження зовнішнього ключа, що вказує на стовпець id таблиці articles. Далі запускаємо міграцію:
$ Rails db: migrate
Rails досить кмітливий, щоб виконувати тільки ті міграції, які ще не були запущені для поточної бази даних, в нашому випадку Ви побачите:
CreateComments: migrating \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d - create_table (: comments) -\u003e 0.0115s \u003d\u003d CreateComments: migrated (0.0119s) \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d
6.2. пов'язуємо моделі
Зв'язки Active Record дозволяють легко оголошувати відносини між двома моделями. У випадку з коментарями та статтями, ви можете описати відносини в такий спосіб:
- Кожен коментар належить одній статті.
- Одна стаття може мати багато коментарів.
Фактично, це дуже близько до синтаксису, який використовує Rails для оголошення цієї зв'язку. Ви вже бачили рядок коду в моделі Comment (app / models / comment.rb), яка робить кожен коментар належить статті:
Class Comment< ApplicationRecord belongs_to:article end
Вам потрібно відредагувати app / models / article.rb, додавши іншу сторону зв'язку:
Class Article< ApplicationRecord has_many:comments validates:title, presence: true, length: { minimum: 5 } [...] end
Ці два оголошення автоматично роблять доступним велику кількість можливостей. Наприклад, якщо у вас є змінна екземпляра @article, що містить статтю, ви можете отримати всі коментарі, що належать цій статті, в масиві, викликавши @ article.comments.
6.3. Додаємо маршрут для коментарів
Як у випадку з контролером welcome, нам потрібно додати маршрут, щоб Rails знав, за якою адресою ми хочемо пройти, щоб побачити коментарі. Знову відкрийте файл config / routes.rb і внесіть необхідні зміни в такий спосіб:
Resources: articles do resources: comments end
Це створить comments як вкладений ресурс в articles. Це інша сторона захоплення ієрархічних відносин, що існують між статтями і коментарями.
6.4. генеруємо контролер
Маючи модель, звернемо свою увагу на створення відповідного контролера. Знову будемо використовувати той же генератор, що використовували раніше:
$ Rails generate controller Comments
Утворюються чотири файли і порожня директорія:
Як і в будь-якому іншому блозі, наші читачі будуть створювати свої коментарі одразу після прочитання статті, і після додавання коментарів вони будуть направлятися назад на сторінку відображення статті і бачити, що їх коментар вже відображений. У зв'язку з цим, наш CommentsController служить в якості засобу створення коментарів і видалення спаму, якщо такий буде.
Спочатку ми розширимо шаблон Article show (app / views / articles / show.html.erb), щоб він дозволяв додати новий коментар:
Title: <%= @article.title %>
Text: <%= @article.text %>
Add a comment:
<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>
<%= form.label:commenter %>
<%= form.text_field:commenter %>
<%= form.label:body %>
<%= form.text_area:body %>
<%= form.submit %>
<% end %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>Це додасть форму на сторінку відображення статті, що створює новий коментар при виклику екшна create в CommentsController. Тут виклик form_with використовує масив, що створить вкладений маршрут, такий як / articles / 1 / comments.
Давайте напишемо create в app / controllers / comments_controller.rb:
Class CommentsController< ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end
Тут все трохи складніше, ніж ви бачили в контролері для статей. Це побічний ефект вкладення, яке ви налаштували. Кожен запит до коментарю відстежує статтю, до якої коментар приєднаний, таким чином спочатку вирішуємо питання з отриманням статті, викликавши find на моделі Article.
Крім того, код користується перевагою деяких методів, доступних для зв'язків. Ми використовуємо метод create на @ article.comments, щоб створити і зберегти коментар. Це автоматично пов'язує коментар так, що він належить до певної статті.
Як тільки ми створили новий коментар, ми повертаємо користувача назад на оригінальну статтю, використовуючи хелпер article_path (@article). Як ми вже бачили, він викликає стрілялки show в ArticlesController, який, в свою чергу, рендерить шаблон show.html.erb. В цьому місці ми хочемо відображати коментарі, тому давайте додамо наступне в app / views / articles / show.html.erb.
Title: <%= @article.title %>
Text: <%= @article.text %>
Comments
<% @article.comments.each do |comment| %>Commenter: <%= comment.commenter %>
Comment: <%= comment.body %>
<% end %>Add a comment:
<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>
<%= form.label:commenter %>
<%= form.text_field:commenter %>
<%= form.label:body %>
<%= form.text_area:body %>
<%= form.submit %>
<% end %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>Тепер у вашому блозі можна додавати статті та коментарі і відображати їх в потрібних місцях.
рефакторинг
Тепер, коли у нас є працюючі статті та коментарі, поглянемо на шаблон app / views / articles / show.html.erb. Він став найдовшим і незручним. Давайте скористаємося партіаламі, щоб розвантажити його.
7.1. Візуалізація колекцій партіалов
Спочатку зробимо партіал для коментарів, що показує всі коментарі для статті. Створіть файл app / views / comments / _comment.html.erb і помістіть в нього наступне:
Commenter: <%= comment.commenter %>
Comment: <%= comment.body %>
Потім можна змінити app / views / articles / show.html.erb ось так:
Title: <%= @article.title %>
Text: <%= @article.text %>
Comments
<%= render @article.comments %>Add a comment:
<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>
<%= form.label:commenter %>
<%= form.text_field:commenter %>
<%= form.label:body %>
<%= form.text_area:body %>
<%= form.submit %>
<% end %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>Тепер це отрендеріть партіал app / views / comments / _comment.html.erb по разу для кожного коментаря в колекції @ article.comments. Так як метод render перебирає колекцію @ article.comments, він призначає кожен коментар локальної змінної з ім'ям, як у партіала, в нашому випадку comment, яка нам доступна в партіале для відображення.
7.2. Візуалізація форми в партіале
Давайте також перемістимо розділ нового коментаря до свого партіал. Знову ж, створіть файл app / views / comments / _form.html.erb, що містить:
<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>
<%= form.label:commenter %>
<%= form.text_field:commenter %>
<%= form.label:body %>
<%= form.text_area:body %>
<%= form.submit %>
<% end %>Потім змініть app / views / articles / show.html.erb наступним чином:
Title: <%= @article.title %>
Text: <%= @article.text %>
Comments
<%= render @article.comments %>Add a comment:
<%= render "comments/form" %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>Другий render всього лише визначає шаблон партіала, який ми хочемо рендерить, comments / form. Rails досить кмітливий, щоб підставити підкреслення в цей рядок і зрозуміти, що Ви хотіли рендерить файл _form.html.erb в директорії app / views / comments.
Об'єкт @article доступний в будь-яких партіалах, рендерящіхся у вьюха, так як ми визначили його як змінну примірника.
видалення коментарів
Іншою важливою особливістю блогу є можливість видалення спаму. Щоб зробити це, потрібно вставити деяку посилання у вьюха та стрілялки destroy в CommentsController.
Commenter: <%= comment.commenter %>
Comment: <%= comment.body %>
<%= link_to "Destroy Comment", , method: :delete, data: { confirm: "Are you sure?" } %>
Натискання цієї нової посилання "Destroy Comment" запустить DELETE / articles /: article_id / comments /: id в нашому CommentsController, який потім буде використовуватися для знаходження коментаря, який ми хочемо видалити, тому давайте додамо стрілялки destroy в наш контролер (app / controllers / comments_controller.rb):
Class CommentsController< ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end def destroy @article = Article.find(params[:article_id]) @comment = @article.comments.find(params[:id]) @comment.destroy redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end
Екшн destroy знайде статтю, яку ми переглядаємо, виявить коментар в колекції @ article.comments і потім прибере його з бази даних і поверне нас назад на перегляд статті.
8.1. Видалення пов'язаних об'єктів
Якщо видаляєте статтю, пов'язані з нею коментарі також повинні бути видалені, в іншому випадку вони будуть просто займати місце в базі даних. Rails дозволяє використовувати опцію dependent на зв'язку для досягнення цього. Модифікуйте модель Article, app / models / article.rb, в такий спосіб:
Class Article< ApplicationRecord has_many:comments, dependent: :destroy validates:title, presence: true, length: { minimum: 5 } [...] end
Безпека
9.1. Базова аутентифікація
Якщо ви опублікуєте свій блог онлайн, будь-хто зможе додавати, редагувати і видаляти статті або видаляти коментарі.
Rails надає базову аутентифікаційні систему HTTP, яка добре працює в цій ситуації.
У ArticlesController нам потрібен спосіб блокувати доступ до різних стрілялки, якщо користувач не аутентифікований. Тут ми можемо використовувати метод Rails http_basic_authenticate_with, що дозволяє доступ до необхідних стрілялки, якщо метод дозволить це.
Щоб використовувати систему аутентифікації, ми визначимо її вгорі нашого ArticlesController в app / controllers / articles_controller.rb. У нашому випадку, ми хочемо, щоб користувач був аутентифікований для кожного екшна, крім index і show, тому напишемо так:
Class ArticlesController< ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", except: [:index, :show] def index @articles = Article.all end # пропущено для краткости
Ми також хочемо дозволити тільки аутентифицироваться користувачам видаляти коментарі, тому в CommentsController (app / controllers / comments_controller.rb) ми напишемо:
Class CommentsController< ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", only: :destroy def create @article = Article.find(params[:article_id]) # ... end # пропущено для краткости
Тепер, якщо спробуєте створити нову статтю, то зустрінетеся з викликом базової аутентифікації HTTP:
Також для додатків на Rails доступні інші методи аутентифікації. Двома популярними доповненнями для Rails, серед інших, є Devise і Authlogic.
9.2. Інші думки про безпеку
Безпека, особливо в веб-додатках, це велика і деталізована область. Безпека вашого застосування Rails розкривається більш детально в керівництві Безпека додатків на Rails Найпростіший спосіб роботи з Rails полягає в зберіганні всіх зовнішніх даних в UTF-8. Якщо не так, бібліотеки Ruby і Rails часто будуть здатні конвертувати ваші рідні дані в UTF-8, але це не завжди надійно працює, тому краще бути впевненим, що всі зовнішні дані є UTF-8.
Якщо ви допускаєте помилку в цій області, найбільш звичайним симптомом є чорний ромб зі знаком питання всередині, з'являється в браузері. Іншим звичайним симптомом є символи, такі як "ü" з'являються замість "ü". Rails робить ряд внутрішніх кроків для пом'якшення загальних випадків тих проблем, які можуть бути автоматично виявлені і виправлені. Однак, якщо є зовнішні дані, які не зберігаються в UTF-8, це може привести до такого роду проблем, які не можуть бути автоматично виявлені Rails і виправлені.
Два найбільш звичайних джерела даних, які не в UTF-8:
- Ваш текстовий редактор: Більшість текстових редакторів (такі як TextMate), за замовчуванням зберігають файли як UTF-8. Якщо ваш текстовий редактор так не робить, це може привести до того, що спеціальні символи, введені в ваші шаблони (такі як é) з'являться як ромб зі знаком питання в браузері. Це також стосується ваших файлів перекладу i18N. Більшість редакторів, які не встановлюють за замовчуванням UTF-8 (такі як деякі версії Dreamweaver) пропонують спосіб змінити умовчання на UTF-8. Зробіть так.
- Ваша база даних: Rails за замовчуванням перетворює дані з вашої бази даних в UTF-8 на кордоні. Однак, якщо ваша база даних не використовує всередині UTF-8, вона може не бути здатною зберігати всі символи, які введе ваш користувач. Наприклад, якщо ваша база даних всередині використовує Latin-1, і ваш користувач вводить російські, івритські або японські символи, дані будуть втрачені як тільки потраплять в базу даних. Якщо можливо, використовуйте UTF-8 як внутрішнє сховище в своїй базі даних.
