Created by: gracewashere
This reverts commit 267edf27.
There are two ways to handle the controller layer for Administrate:
- Generate a single controller,
Admin::ApplicationController, and route the RESTful actions for all resource types through it. Let users subclass the controller to create resource-specific behavior. - Generate
Admin::ApplicationController, which contains all of the defaultRESTfullogic, as well as empty subclasses for each resource type. If users want to customize controller actions in the future, this saves them a generator step.
We originally went with option 2, before switching to option 1 in 267edf27.
That switch came in the wake of adding Administrate to Hound. We decided to change to a single controller to reduce the diff noise from the administrate:install generator.
Recently, we've started adding Administrate to Upcase. Upcase is a more complex application, and needs more customization off the bat. After attempting several customizations, it's clear that it would be much cleaner/easier to customize if the relevant controller subclasses had been pre-generated.
Some examples of customizations we've needed to make are:
- defining custom resource finders (e.g. to look up a product by a slug)
- overriding a view for a single resource type (Rails needs the subclass chain to look up the correct view to render)
This change also makes routing significantly cleaner, letting us use the resources method without additional arguments.
Many of these problems could be solved by taking option 1, and writing very good documentation & controller/view generators, but as an MVP I believe it's cleaner and clearer for developers to explicitly define the controller subclasses up front.