Ласкаво просимо / домашня сторінка в Ruby on Rails - найкраща практика


80

Моя домашня сторінка (або привітальна сторінка) буде складатися з даних двох моделей (давайте називати їх авторами та публікаціями). Я новачок у рейках і не знаю, який найкращий спосіб досягти цього.

Чи повинен я створити новий контролер, який називається вітанням, який збирає дані від авторів та публікацій, а потім відображає їх у поданні індексу вітань? Або я повинен мати привітальний погляд під моделлю публікації, яка також отримує дані від авторів? Або будь-яким іншим способом досягти цього?

Я розумію, як зробити все це технічно, але просто не впевнений, що є найкращим методом на практиці, використовуючи структуру рейок.

Відповіді:


52

Питання в тому, чи є ваша домашня сторінка лише цільовою сторінкою чи це буде група сторінок? Якщо це лише цільова сторінка, ви не очікуєте, що ваші користувачі будуть довго там затримуватися, крім того, щоб піти в інше місце. Якщо це група сторінок або подібна до існуючої групи, ви можете додати дію до контролера, який найбільше подобається.

Для свого поточного проекту я зробив контролер з іменем Static, тому що мені потрібні 3 статичні сторінки. Домашня сторінка - одна з таких, бо там нічого не можна побачити чи зробити, крім як перейти в інше місце.

Щоб зіставити маршрут за замовчуванням, використовуйте наступне routes.rb:

# Place at the end of the routing!
map.root :controller => 'MyController', :action => :index

У моєму випадку це буде:

map.root :controller => 'static', :action => :index

За бажанням ви можете створити контролер саме для цієї домашньої сторінки. Я б назвав це основним, або як-небудь, що ви пам’ятаєте, що стосується домашньої сторінки. Звідти ви можете отримати свої дані та свої моделі та відкласти їх до вихідного подання.

class MainController < ApplicationController
  def index
    @posts = Posts.find(:all, :limit => 10, :order => 'date_posted', :include => :user)
  end
end

Якщо припустити, що ви правильно визначили свої зв’язки з моделями, шаблон відповідати йому буде дуже простим.

Удачі, сподіваюся, це допоможе.


Отже, написання @posts = Posts.find( ...або @posts = Posts.allщось подібне в цьому новому контролері / дії не вважатиметься порушенням принципів СУХОГО, навіть якщо такий код може вже з’являтися в дії Postконтролера index? Чи є кращий (більш модульний) спосіб, який використовує вже написаний код дії Postконтролера index?
— LazerSharks

127

Здається, не існує жодної найкращої практики.

(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 майже однакові, крім слова "статичний".


12
Приємна відповідь, я оберу 2) сторінки # додому.
— Neeraj

3
IMHO, ця відповідь @ user664833 повинна бути прийнятою відповіддю. Висловлюючи чітко досліджену і розглянуту логіку.
— Betjamin Richards

29

Я запитав себе приблизно так, коли вперше запустив Rails. Ось що вам потрібно знати:

  • Моделі не обов'язково безпосередньо пов'язані з контролерами та поданнями.

Тобто певна комбінація контролера / подання може працювати з такою кількістю моделей, скільки потрібно для створення цієї конкретної сторінки.

Призначення контролера - підготувати набір даних, який потрібно відобразити, незалежно від того, які моделі використовуються для зберігання цих даних.

Метою подання є відображення цих даних найбільш відповідним чином.

Іншими словами, комбінації контролер / вигляд ніколи не є «під» певної моделі. Вони використовують моделі, але не знаходяться під ними в жодних ієрархічних відносинах. Насправді вони є однолітками з будь-якими моделями, якими вони користуються.

Я думаю, плутанина походить від прикладу генератора лісів, який міститься в AWDR та інших вступних текстах, таких як:

рубіновий скрипт / згенерувати контролер моделі лісів

Я знаю, що це неявне співвідношення між моделлю та контролером / поглядами мене трохи збентежило. Але насправді немає суворих стосунків. Якби вони були, тоді було б дуже важко зробити щось складне з підходом MVC. І зрозуміло, це не так.

Сподіваюся, це допомагає.

- Джон


10
Яка ваша відповідь на запитання?
— Mark Wilden

Замість того, щоб конкурувати з іншими відповідями (які більш безпосередньо пов’язані з проблемою, що виникає у допитувача), це пов’язано з помилковим уявленням, яке, на думку Джона, має запитувач. Це корисно. Немає жодних причин для Джона повторювати те, що говорили інші, щоб розглянути той аспект питання, якого вони не розглядали.
— іконоборці

11

Найкращою практикою буде ваша перша пропозиція. Створіть контролер "привітання" і викликайте записи з будь-якої моделі, яку ви хочете. Майте кореневу точку маршруту до цього контролера. Дуже чисто і правильно.


9

Зверніть увагу, що в Rails3 правильним способом цього є додавання наступного рядка в кінець файла routes.rb:

root :to => "welcome#index"

та видаліть public / index.html.erb.

Також зауважте, що привітальний # індекс відповідає дії індексу у WelcomeController, а код відповіді The Wicked Flea виглядатиме так:

class WelcomeController < ApplicationController
  def index
    @posts = Posts.find(:all, :limit => 10, :order => 'date_posted', :include => :user)
  end
end

1
Якщо це не контролер "вітає", чи окремий ресурс, скористайтеся дією show.
— dangerousdave

9

Ця відповідь стосується Rails 3.2.1.

Спочатку налаштуйте контролер для сторінок, названих, наприклад static:

$ rails generate controller static

У файлі app/controllers/static_controller.rb:

class StaticController < ApplicationController
    def index       
    end
end

Створіть новий файл перегляду app/views/index.html.erb

І нарешті налаштуйте config/routes.rb:

MyApp::Application.routes.draw do
   match 'home', :to => "static#index"
   root :to => "static#index"
end

Це зробить обидва /homeі /перейде до того, що ви вкладете у щойно створений файл перегляду.


Дуже приємне рішення! Мене роздратовує, але я б запропонував прочитати другий рядокmatch 'home' => 'static#index'
— Анконія

6

Створіть новий контролер, названий якомога доречніше. РезюмеКонтролер? StartController? DailyFrontPageController? У вас буде ідея.

Мало того, я б серйозно задумався про створення нової Моделі, не на основі ActiveRecord, яка збирає інформацію з Ваших моделей Автор та Пошта (або незалежно від їх справжнього імені) для презентації на Ваш погляд. Альтернативою є збір даних у контролері, який майже напевно буде брудним - це було кожного разу, коли я це пробував, і я багато разів пробував. Здається, окрема модель закінчується набагато акуратніше.

Якщо обробка є відносно простою, чому б не спробувати спочатку побудувати дані в контролері, а потім обернути висновок у структуру, а потім замінити структуру реальним класом і перемістити конструкцію туди, рефакторинг до кінця. Це не повинно додавати занадто багато до загального часу (більшу частину коду можна використовувати повторно), і ви отримаєте гарне уявлення про те, що вам найкраще підходить.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.