← Back to Upcase

Best Practices for Controllers Serving Aggregate Views


(Lance Johnson) #1

What are some best practices around an aggregate page in Rails/Ruby webapps? By an aggregate page, I mean a page in an application that displays data from several different models and has functionality for operating on some of those models.

I’m currently working in a Padrino app and we have some “dashboard” views that aggregate data and functionality for several different models but itself has no model. Our current “dashboard” controller is accessing each of the models independently and storing each result its own instance variable (almost 20) for the view to render. You should probably know too that all of the data is coming from a web API, not from our app database.

I suspect that this is less than the best approach. What are better approaches for these types of situations? Should we introduce a dashboard model that aggregates the data so the controller only instantiates that object?

Any advice you can offer is greatly appreciated.


(Jurre) #2

Yes, I think some sort of Dashboard object makes a lot of sense in this case. You could also look into the Cells gem.


(Austin ) #3

Having a single object that encapsulates those variables is very helpful. If you need a pair I’d be happy to help for a bit.


(Lance Johnson) #4

Thanks for the advice. Thanks also for the offer to pair. Unfortunately, there is proprietary information in the app that my company will not allow outside our org.