Здається, не існує жодної найкращої практики.
(1)config/routes.rb Здається, що стандартний файл передбачає, що кореневою сторінкою (або домашньою / вітальною сторінкою) повинна бути оброблена welcome#index. Якщо ви мали керуватися цим, то для створення відповідного welcome#indexконтролера / дії ви можете використовувати таку команду:
rails generate controller Welcome index
Потім, у config/routes.rb, ви можете видалити get "welcome/index"автоматично доданий генератором шлях GET ( ), і розмістити кореневий маршрут root 'welcome#index'(або root :to => 'welcome#index'в Rails < 4) у верхній частині файлу, оскільки це, мабуть, буде вашим найпопулярнішим маршрутом і йому слід відповідати спочатку.
Також пам’ятайте про видалення public/index.htmlв Rails < 4.
(2) Офіційний Рубін на Rails Routing керівництво використання PagesController. Це насправді підказує pages#main, хоча для мене це має сенс піти далі pages#home(оскільки "домашня сторінка" - це всюдисущий термін / поняття). Крім того, цей контролер може обробляти інші сторінки , орієнтовані на такі дії, як pages#about, pages#contact, pages#terms, pages#privacyі т.д.
(3) Підручник з Ruby on Rails , поєднується з static_pages#homeі static_pages#helpт. Д., Хоча мені не подобається ідея позначати цей контролер як "статичний". Ці сторінки все ще матимуть певні динамічні аспекти, зокрема домашню сторінку!
(4) Хоча в ньому не обговорюється, як обробляти домашню сторінку , RailsCast # 117 на напівстатичних сторінках пропонує ще один набір підходів до показу лише ресурсів.
Я відчуваю перевагу до 1 та / або 2. За сценарієм "і" ви можете використовувати індекс привітання та сторінки # про, тощо, тоді як для сценарію "або" ви можете використовувати сторінки # додому, сторінки # про, і т. д. Якщо мене змусять вибрати, я б вибрав варіант 2 лише тому, що в підсумку у вас менше коду. До речі, 2 і 3 майже однакові, крім слова "статичний".
@posts = Posts.find( ...або@posts = Posts.allщось подібне в цьому новому контролері / дії не вважатиметься порушенням принципів СУХОГО, навіть якщо такий код може вже з’являтися в діїPostконтролераindex? Чи є кращий (більш модульний) спосіб, який використовує вже написаний код діїPostконтролераindex?