# Refactoring views ? Should public class methods be used in views? **URL:** \ **Category:** Rails\ **Created:** [July 24, 2010, 5:02pm UTC](https://www.ruby-forum.com/t/refactoring-views-should-public-class-methods-be-used-in-views/192137 "2010-07-24T17:02:16Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![marmolin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/71e660/32.png) [@marmolin](https://www.ruby-forum.com/u/marmolin)\ **Post date:** [July 24, 2010, 5:02pm UTC](https://www.ruby-forum.com/t/refactoring-views-should-public-class-methods-be-used-in-views/192137/1 "2010-07-24T17:02:16Z")
I am refactoring my views and have learned that to separate view controller and models and that the view is feed from the controller that defines the instance variables related to a the models that is to be used in views- I have also learned that the number of inctace variables should be limited to 1-2 in each action. My question is about how to handle public class methods. In some actions I have many such methods for objects as Person, User etc and I could either define instance variables (but there will then be to many) or specific presenters for these variables or putting them directly into the views to define i.e select\_tags with different option lists What solution is to be preferred ? select\_tag(:person\_id, options\_for\_select(@people\_list.insert(0, [‘Select a person’,0]),@selected\_person.to\_s),… select\_tag(:person\_id, options\_for\_select(Person.all\_people.insert(0, [‘Select a person’,0]),Person.current.to\_s),… select\_tag(:person\_id, options\_for\_select(PeoplePresenter.all\_people.insert(0,[‘Select a person’,0]),PeoplePresenter.current\_person.to\_s),… etc ---
**Author:** ![marmolin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/71e660/32.png) [@marmolin](https://www.ruby-forum.com/u/marmolin)\ **Post date:** [July 24, 2010, 6:24pm UTC](https://www.ruby-forum.com/t/refactoring-views-should-public-class-methods-be-used-in-views/192137/2 "2010-07-24T18:24:49Z")
On Sat, Jul 24, 2010 at 12:00 PM, Hans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > be to many) or specific presenters for these variables or putting them > person’,0]),PeoplePresenter.current\_person.to\_s),… > etc You should not use your models within your views. Use controller’s instance variables in your views. – Leonardo M… There’s no place like ~ ---
**Author:** ![marmolin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/71e660/32.png) [@marmolin](https://www.ruby-forum.com/u/marmolin)\ **Post date:** [July 24, 2010, 11:16pm UTC](https://www.ruby-forum.com/t/refactoring-views-should-public-class-methods-be-used-in-views/192137/3 "2010-07-24T23:16:21Z")
Thanks for the advice As that means a lot of controller instance variables I then had to define a presenter with methods calling public class methods as Person.all\_people, Person.current etc ---
**Author:** ![marmolin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/71e660/32.png) [@marmolin](https://www.ruby-forum.com/u/marmolin)\ **Post date:** [July 25, 2010, 9:50pm UTC](https://www.ruby-forum.com/t/refactoring-views-should-public-class-methods-be-used-in-views/192137/4 "2010-07-25T21:50:41Z")
On Sat, Jul 24, 2010 at 6:15 PM, Hans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Thanks for the advice > As that means a lot of controller instance variables I then had to > define a presenter > I’m not sure what you mean with this, but you can use helper methods > to clean up your views and make them easier to maintain. > with methods calling public class methods as Person.all\_people, > Person.current etc > I can’t tell you about this, since that’s just a matter of your > application design. > > > My question is about how to handle public class methods. > > > [‘Select a person’,0]),Person.current.to\_s),… > > > There’s no place like ~ > > – > You received this message because you are subscribed to the Google G. “Ruby on Rails: Talk” group. > To post to this group, send email to removed\_email\_address@domain.invalid. > To unsubscribe from this group, send email to removed\_email\_address@domain.invalid. > For more options, visit this group at [http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en). – Leonardo M… There’s no place like ~