Ask A Question
Notifications
You’re not receiving notifications from this thread.
Best Method For User's Dashboard?
Hi, I am looking for advice on the best way to organize a dashboard to show the user various information from across different models.
I was considering just generating a DasboardsController, but that doesn't seem very rails-y - for starts because of the fact that it is plural when in reality, it just needs to be DashboardController#index.
My app is set up in the following way:
Users
|
Businesses
|
Locations
| |
| Requests
Payments
OtherThings
I considered simply adding businesses#dashboard, but that seems wrong. I am trying to display chunks of info from children of the business model.
Any suggestions on design pattern here?
Cheers!
I was considering just generating a DasboardsController, but that doesn't seem very rails-y - for starts because of the fact that it is plural when in reality, it just needs to be DashboardController#index.
My app is set up in the following way:
Users
|
Businesses
|
Locations
| |
| Requests
Payments
OtherThings
I considered simply adding businesses#dashboard, but that seems wrong. I am trying to display chunks of info from children of the business model.
Any suggestions on design pattern here?
Cheers!
Hi Rich,
When I do dashboards, I generally create a singular route, e.g. `resource :dashboard, only: :show`.
That way, you can have a singular controller name. To organize the data that will be displayed, either create a `Dashboard` model as a plain ruby object, or a `DashboardPresenter`. You can expose that object in your view with `helper_method`.
Your instinct to create a dedicated controller was the right one imo. As far as the end-user is concerned, a dashboard is a resource, even if in technical terms, is it just an aggregate of other data.
> I considered simply adding businesses#dashboard, but that seems wrong.
Same feeling. When I'm tempted to create a non-REST method in a controller, I often realize that's the smell for the need of a discrete resource.
Hope that helps!
When I do dashboards, I generally create a singular route, e.g. `resource :dashboard, only: :show`.
That way, you can have a singular controller name. To organize the data that will be displayed, either create a `Dashboard` model as a plain ruby object, or a `DashboardPresenter`. You can expose that object in your view with `helper_method`.
Your instinct to create a dedicated controller was the right one imo. As far as the end-user is concerned, a dashboard is a resource, even if in technical terms, is it just an aggregate of other data.
> I considered simply adding businesses#dashboard, but that seems wrong.
Same feeling. When I'm tempted to create a non-REST method in a controller, I often realize that's the smell for the need of a discrete resource.
Hope that helps!