Aquí tiene dos opciones, dependiendo de cuánto se vincule su lógica y su vista al alcance. Déjame explicarte más.
La primera opción es determinar el alcance dentro de su controlador, como ya se explicó en las otras respuestas. Normalmente establezco una variable @scope para obtener algunos beneficios adicionales en mis plantillas.
class Articles
before_filter :determine_scope
def index
@articles = @scope.all
# ...
end
protected
def determine_scope
@scope = if params[:category_id]
Category.find(params[:category_id]).articles
else
Article
end
end
end
La razón de la variable @scope es que puede que tenga que conocer el alcance de su solicitud fuera de la única acción. Supongamos que desea mostrar el número de registros en su vista. Necesita saber si está filtrando por categoría o no. En este caso, solo necesita llamar al @scope.count
o @scope.my_named_scope.count
en lugar de repetir cada vez que se verifique params[:category_id]
.
Este enfoque funciona bien si sus vistas, la que tiene categoría y la que no tiene categoría, son bastante similares. Pero, ¿qué sucede cuando la lista filtrada por categoría es completamente diferente en comparación con la que no tiene una categoría? Esto sucede bastante a menudo: la sección de su categoría proporciona algunos widgets centrados en la categoría, mientras que la sección del artículo incluye algunos widgets y filtros relacionados con el artículo. Además, su controlador de artículo tiene algunos before -filters especiales que quizás quiera usar, pero no tiene que usarlos cuando la lista de artículos pertenece a una categoría.
En este caso, es posible que desee separar las acciones.
map.resources articles
map.resources categories, :collection => { :articles => :get }
articles_path # /articles and ArticlesController#index
category_articles_path(1) # /category/1/articles and CategoriesController#articles
Ahora la lista filtrada por categoría es administrado por el CategoriesController
y hereda todos los filtros, los diseños, los ajustes del regulador ... mientras que la lista sin filtrar es dirigido por el ArticlesController
.
Normalmente esta es mi opción favorita porque con una acción adicional no tiene que saturar sus vistas y controladores con toneladas de comprobaciones condicionales.
este es exactamente el otro problema al que me enfrentaba, necesitaba renderizar diferentes vistas también. – knoopx
también, does: shallow tiene sentido en esta ruta en particular? – knoopx
Si no utiliza: superficial necesita una forma de asignar la ruta/articles así que, sí, en mi humilde opinión, tiene sentido. –