Bienvenido / página de inicio en Ruby on Rails - mejores prácticas


80

Mi página de inicio (o página de bienvenida) consistirá en datos de dos modelos (llamémoslos autores y publicaciones). Soy nuevo en los rieles y no estoy seguro de cuál es la mejor manera de lograrlo.

¿Debo crear un nuevo controlador llamado welcome que recopile datos de los autores y publicaciones y luego los muestre en la vista del índice de bienvenida? ¿O debería tener una vista de bienvenida bajo el modelo de publicación que también obtiene datos de los autores? ¿O alguna otra forma de lograr esto?

Entiendo cómo hacer todo esto técnicamente, pero no estoy seguro de cuál es el método de mejores prácticas utilizando el marco de rieles.

Respuestas:


51

La pregunta es, ¿su página de inicio es solo una página de destino o será un grupo de páginas? Si es solo una página de destino, no espera que sus usuarios permanezcan allí por mucho tiempo, excepto para ir a otra parte. Si es un grupo de páginas, o similar a un grupo existente, puede agregar una acción al controlador que más le guste.

Lo que he hecho para mi proyecto actual es crear un controlador con nombre Static, porque necesito 3 páginas estáticas. La página de inicio es una de ellas, porque no hay nada que ver o hacer excepto ir a otra parte.

Para mapear una ruta predeterminada, use lo siguiente en routes.rb:

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

En mi caso esto sería:

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

Si lo desea, puede crear un controlador solo para esta página de inicio. Lo llamaría principal, o algo que puedas recordar que se relacione con la página de inicio. Desde allí, puede obtener sus datos y sus modelos y pasar a la vista de salida.

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

Suponiendo que tiene las relaciones de su modelo definidas correctamente, la plantilla para que coincida será muy simple.

Buena suerte, espero que esto sirva.


Entonces, escribir @posts = Posts.find( ...o @posts = Posts.allalgo 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ón Postdel controlador index. ¿Existe una forma mejor (más modular), que utiliza el código ya escrito de la acción Postdel controlador index?
LazerSharks

127

No parece haber una sola mejor práctica.

(1) El config/routes.rbarchivo 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#indexcontrolador / 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.htmlen 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#homey 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".


12
Buena respuesta, elegiré 2) páginas # inicio.
Neeraj

3
En mi humilde opinión, esta respuesta de @ user664833 debería ser la respuesta aceptada. Expresar una lógica claramente investigada y considerada.
Betjamin Richards

29

Me pregunté algo como esto cuando comencé Rails. Esto es lo que necesita saber:

  • Los modelos no están necesariamente relacionados directamente con los controladores y las vistas.

Es decir, una combinación particular de controlador / vista puede funcionar con tantos modelos como necesite para generar esa página en particular.

El propósito del controlador es preparar el conjunto de datos que necesita mostrar, independientemente de los modelos que se utilicen para almacenar esos datos.

El propósito de la vista es luego mostrar esos datos de la manera más apropiada.

En otras palabras, las combinaciones de controlador / vista nunca están "debajo" de un modelo en particular. Usan modelos, pero no están bajo ellos en ninguna relación jerárquica. De hecho, son iguales a cualquier modelo que utilicen.

Creo que la confusión proviene del ejemplo del generador de andamios que se encuentra en AWDR y otros textos introductorios, como:

script ruby ​​/ generar controlador de modelo de andamio

Sé que esta relación implícita entre modelo y controlador / vistas me confundió un poco. Pero en realidad no existe una relación estricta. Si lo hubiera, sería muy difícil hacer algo complicado con el enfoque MVC. Y claramente, ese no es el caso.

Espero que esto ayude.

-- Juan


10
¿Cuál es tu respuesta a la pregunta?
Mark Wilden

En lugar de competir con otras respuestas (que están más directamente relacionadas con el problema que presenta el interrogador), esto se relaciona con un concepto erróneo que John percibe que tiene el interrogador. Esto es útil. No hay ninguna razón para que John repita lo que otros han dicho para abordar un aspecto de la pregunta que no abordaron.
iconoclasta

11

La mejor práctica sería su primera sugerencia. Cree un controlador de 'bienvenida' y llame a los registros de los modelos que desee. Tener un punto de ruta raíz a ese controlador. Muy limpio y adecuado.


9

Tenga en cuenta que en Rails3, la forma correcta de manejar esto es agregar la siguiente línea al final del archivo route.rb:

root :to => "welcome#index"

y elimine public / index.html.erb.

Tenga en cuenta también que el índice # de bienvenida corresponde a la acción de índice en un controlador de bienvenida y el código de la respuesta de The Wicked Flea se vería así:

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

1
¿No debería ser un controlador "bienvenido" o para un recurso singular, use la acción mostrar.
dangerousdave

9

Esta respuesta es de Rails 3.2.1.

Primero configure un controlador para las páginas, llamado por ejemplo static:

$ rails generate controller static

En archivo app/controllers/static_controller.rb:

class StaticController < ApplicationController
    def index       
    end
end

Crea el nuevo archivo de vista app/views/index.html.erb

Y finalmente configura tu config/routes.rb:

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

Esto hará que ambos /homee /irán a lo que haya puesto en el archivo de vista que acaba de crear.


¡Muy buena solución! Estoy siendo quisquilloso, pero sugeriría que se lea la segunda líneamatch 'home' => 'static#index'
Anconia

6

Cree un nuevo controlador con el nombre más apropiado que pueda. SummaryController? StartController? DailyFrontPageController? Tendrás una idea.

No solo eso, consideraría seriamente la creación de un nuevo modelo, no basado en ActiveRecord, que recopile la información de sus modelos de autor y publicación (o cualquiera que sea su nombre real) para presentarla en su vista. La alternativa es ensamblar los datos en el controlador, lo que seguramente será complicado; lo fue cada vez que lo probé, y lo intenté mucho. Un modelo separado parece terminar mucho más ordenado.

Si el procesamiento es relativamente sencillo, ¿por qué no intentar construir los datos en el controlador primero, luego envolver la salida en un Struct, luego reemplazar el Struct con una clase real y mover la construcción allí, refactorizando todo el camino? No debería agregar demasiado al tiempo total (la mayor parte del código se puede reutilizar) y obtendrá una buena idea de lo que funciona mejor para usted.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.