Ласкаво просимо / домашня сторінка в 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.