ck.> > Anyhow, my current ideas for solutions, none of which I really like, > are as follows: > 1. In the "create" and "update" actions, call the filter methods > prior to rendering the new/edit views (don't like this, since if > additional reference data is added later, I will have to add/remove > more method calls) > > 2. Add additional helper methods that set all of the reference data > for a particular action (i.e. find_ref_data_for_new) (this is better > than option 1, but would still potentially have to modify code in > multiple locations) > > 3. Add "create" and "update" to the list of actions included in the > before_filter (this would work, but it just doesn't make sense, since > "create" and "update" are really DB related actions, and only display > data when some DB operation, or validation, fails) >
#1: Dislike this for your very reasons. #3: Dislike this because I like the idea of parsimony in the execution of the application. In the create and update actions, you don't always need that reference data, and to fetch that data every time, is unnecessary. #2: Seems to be the best compromise between too much coding, and too much execution. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
