I am working on re-factoring my admittedly ambitious employee management Rails app that I created for work. The good news is, my first major version went over like a dream(With no small amount of thanks due to the community and the support)! All of the functionality the bosses dreamed of! The bad news? It's REALLY SLOW. So I rolled up my sleeves and have been working on some re-writes that are showing a tremendous amount of progress(This is my first major app!)
My initial page crunches and loads data from 5 separate tables. There is a lot of logic that goes into supporting the Model the entire app is designed around (appropriately named the DaySchedule object). Within the views there are a lot of calls made from database associations(DaySchedule.employee.full_name, DaySchedule.assignment.assignment_name, you get the idea). These related models are vital for the views, but I know that they are killing my render time . . . I also know that db access in the views is a big no no. I was wondering what others did when faced with this? My thought has been to initialize a bunch of "virtual attributes" when instantiating the DaySchedule object back in the model. (going from DaySchedule.employee.full_name to a DaySchedule.full_name method that I set up with initialize so it is in memory). Does this sound like the right thing to do? What are best practices when an object has a large amount of associations with other models and the view needs access to those related objects? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
