No parece haber una sola mejor práctica.
(1) El config/routes.rb
archivo estándar parece sugerir que la página raíz (o la página de inicio / bienvenida) debe ser manejada por welcome#index
. Si tuviera que guiarse por eso, entonces para generar el welcome#index
controlador / acción correspondiente , puede usar el siguiente comando:
rails generate controller Welcome index
Luego, en config/routes.rb
, puede eliminar la ruta GET ( get "welcome/index"
) agregada automáticamente por el generador y colocar la ruta raíz root 'welcome#index'
(o root :to => 'welcome#index'
en Rails < 4
) en la parte superior del archivo, porque probablemente será su ruta más popular y debería coincidir primero.
También recuerde eliminar public/index.html
en Rails < 4
.
(2) La guía de enrutamiento oficial de Ruby on Rails utiliza PagesController
. En realidad sugiere pages#main
, aunque para mí tiene más sentido seguir pages#home
(porque "página de inicio" es el término / concepto omnipresente). Además, este controlador puede manejar otras orientado a la página acciones tales como pages#about
, pages#contact
, pages#terms
, pages#privacy
, etc.
(3) El Tutorial de Ruby on Rails , va con static_pages#home
y static_pages#help
, etc., aunque no me gusta la idea de denotar este controlador con "estático". Es probable que estas páginas aún tengan algunos aspectos dinámicos, ¡particularmente la página de inicio!
(4) Aunque no analiza cómo manejar una página de inicio , RailsCast # 117 en páginas semiestáticas sugiere otro conjunto de enfoques para mostrar solo recursos.
Siento preferencia por 1 y / o 2. Con el escenario "y", podría usar # índice de bienvenida y páginas # acerca, etc., mientras que con el escenario "o", podría usar páginas # inicio, páginas # acerca, etc. Si me obligara a elegir, optaría por la opción 2 solo porque terminas con menos código. Y por cierto, 2 y 3 son prácticamente iguales, aparte de la palabra "estática".
@posts = Posts.find( ...
o@posts = Posts.all
algo similar en este nuevo controlador / acción no se consideraría una violación de los principios de DRY, aunque tal código ya puede aparecer en la acciónPost
del controladorindex
. ¿Existe una forma mejor (más modular), que utiliza el código ya escrito de la acciónPost
del controladorindex
?