Poner la lógica de presentación en el controlador es una buena práctica en Ruby?

Question

Alguna recomendación [1] sugieren que el uso de

<%= current_user.welcome_message %>

en lugar de

<% if current_user.admin? %>
  <%= current_user.admin_welcome_message %>
<% else %>
  <%= current_user.user_welcome_message %>
<% end %>

Pero el problema es que usted debe tener la lógica de la decisión en algún lugar en el código.

Mi entendimiento es poner la decisión en template es mejor que controller como hacer que su controlador más limpio.Es correcto?

¿Hay mejor manera de manejar esto?

http://robots.thoughtbot.com/post/27572137956/tell-dont-ask

Answer 1

En mi opinión, si el texto es lo único que cambia, no pertenece a una vista.Si necesitaba reestructurar la página, esa es la lógica de presentación.Esto, esto es solo que los datos son diferentes.

Answer 2

No eres el primero en preguntarte esto. Si las vistas y los controladores deben tener poca o ninguna lógica, y el modelo debe ser la presentación agnóstica, ¿a dónde pertenece la lógica de presentación?

Resulta que podemos usar una técnica antigua llamada el patrón de decorador . La idea es envolver su objeto modelo con otra clase que contiene su lógica de presentación. Esta clase de envoltura se llama Decorator . El decorador abstrae la lógica de su vista, mientras mantiene sus modelos aislados de su presentación.

draper es una excelente gema que ayuda a definir decoradores.

El código de muestra que dio podría ser abstraído así:

Pase un decorador a la vista con @user = UserDecorator.new current_user en su controlador.

Tu decorador podría verse de abajo.

class UserDecorator
  decorates :user

  def welcome_message
    if user.admin?
      "Welcome back, boss"
    else
      "Welcome, #{user.first_name}"
    end
  end
end

y su vista simplemente contendría @user.welcome_message

Observe que el modelo en sí no contiene la lógica para crear los mensajes. En su lugar, el decorador envuelve el modelo y traduce los datos del modelo en una forma presentable.

espero que esto ayude!

Answer 3

Yo usaría un ayudante para esto.Supongamos que tiene que traducir el mensaje de bienvenida, según un lugar local.

en la escritura de app/helper/user_helper.rb escribe

module UserHelper

  def welcome_message(user)
    if user.admin?
      I18n.t("admin_welcome_message", :name => user.name)
    else
      I18n.t("user_welcome_message", :name => user.name)
    end
  end 

end

y en su opinión, entonces puede escribir

<%= welcome_message(user) %>

Tenga en cuenta que el decorador / presentador ofrece un enfoque muy limpio orientado a objetos, pero IMHO usando un ayudante es mucho más simple y suficiente.

Answer 4

No, no quiere ningún condicional en absoluto en la clase de usuario ni en el controlador.El punto de ese ejemplo en la publicación del blog es hacer referencia al polimorfismo, solo un buen diseño de OO antiguo.

# in application_controller for example
def current_user
  if signed_in?
    User.find(session[:user_id])
  else
    Guest.new
  end  
end

#app/models/user.rb
class User
   def welcome_message
     "hello #{name}"
   end
end

#app/models/guest.rb
class Guest
  def welcome_message
    "welcome newcomer"
  end
end

... obtienes la idea.

Solo, en lugar de ensuciar su modelo con métodos de solo presentación, cree un decorador que actúa como un presentador:

require 'delegate'
class UserPresenter < SimpleDelegator
  def welcome_message
    "hello #{name}"
  end
end

y ahora current_user se ve así:

# application_controller
def current_user
  if signed_in?
    UserPresenter.new(User.find(session[:user_id]))
  else
    Guest.new
  end
end

Answer 5

Decore el modelo de usuario y agregue la biAnT_Message a él directamente.Sí, esto puede implicar algún tipo de declaración condicional en algún momento.

http://robots.thughbot.com/post/14825364877 / Evaluación-Alternative-Decorator-Implementations-in

Answer 6

Creo que deberías ver el episodio de RailsCasts en presentadores para la respuesta.

Answer 7

lógica En la vista es difícil de mantener, deberíamos poner la lógica empresarial en el modelo y en todas las lógicas de la vista en los ayudantes.

Si desea que su código esté en la moda orientada a objetos, haga uso de los decoradores (forma orientada a los objetos de los ayudantes)

El mejor ejemplo: https://github.com/jcasimir/draper

Answer 8

Poner el código de la definición de current_user.welcome_message en _app/helpers/application_helper.rb_, será accesible por cualquier vista que se genera con el aplicación diseño.

Otra opción es definir una personalizado ayudante de módulo, que no está necesariamente asociado con una determinada vista o controlador (Ver el vídeo que he enlazado más abajo), y include en los módulos de la vista de los controladores/usted desea tener esa funcionalidad.

Esto no es algo que está en blanco y negro.Pero, a partir de lo que he descrito como suena este es el código que se molesta a pegarse en su application_controller.rb y no es de código con la funcionalidad que justifica su propio controlador, la opción más eficaz y eficiente puede ser crear un helper personalizado módulo e incluir en él a los ayudantes usted desea tener esa funcionalidad.Dicho esto, es en última instancia un juicio que el diseñador de la aplicación (es decir, usted) debe decidir.

Aquí es un buen artículo que resume ayudante de módulos de Mayo, 2011

Aquí se trata de un RailsCast delineando personalizado ayudante de módulos (es decir,la costumbre como en los módulos, no necesariamente asociada a un determinado controlador o vista).Corto, dulce, y al punto.

Answer 9

Puede definir el método de ayuda para eso.No creo que sea una buena idea hacer una buena idea en un modelo, pero también en el controlador.Pero debe intentar que se vuelvan limpios de código, y si puede usar ayudantes para eso, entonces debe hacerlo.

Answer 10

Una buena práctica sería real View las instancias.Rieles de la parodia de MVP (no hay diferencia, buscar) por desgracia parece pretender que las vistas son plantillas.Que está mal.

Las vistas se supone que contienen la lógica de presentación en MVC y MVC-inspirado en patrones.Se supone, además, para manipular múltiples plantillas y la toma de decisiones en el que las plantillas a utilizar para representar el estado y la información de la capa del modelo (sí, el modelo es una capa no un ORM ejemplo).

Así que, para responder a la pregunta: la lógica de presentación, no tiene lugar en los controladores.