Hi there, Ok that statement was probably a bit ambiguous. I'd use a view helper to encapsulate something that is purely view based. I'd say that commified_name isn't confined to the view, its legitimately an attribute of the model - model attributes aren't confined to database attributes. I don't think that would break convention at all. The convention is there to make things easier to manage, separating that logic into a view helper would make it, in my eyes less easy to manage.
Generally I would go with whatever solution feels more natural, and easier to manage for you. Don't get bogged down in convention if it doesn't work for you or feels wrong. RobL http://www.robl.me ericindc wrote: > Thanks for the reply. > > "I'd only really use a helper method to encapsulate repeated code in > views." > > But isn't that the case here? I repeatedly use the commified version > of the name inside of my views. So why wouldn't C be the best > solution? Wouldn't using A break that convention? > > I also use the commified version of the name inside of a > collection_select statement, so that the displayed names in the > dropdown menu are "last_name, first_name". The only way I've found to > do that is to have a method inside of my Project model that returns > the commified name, even though the collection_select is inside of my > Project View. > > So I guess given that, C is the best solution to avoid repetition > (commified_name in Model and Helper)? > > Thanks > > On Jan 31, 7:07 am, Rob Lacey <r...@mail.pigdestroyer.co.uk> wrote: > >> I would always go for A >> >> def commified_name >> "#{self.firstname} #{self.last_name}" >> end >> >> It keeps the formatting in one place, no need for an additional helper >> method or indeed a helper class. I'd only really use a helper method to >> encapsulate repeated code in views. Just suppose you wanted to see the >> commified name in the console or use it to perform some kind of >> validation, etc. >> >> RobL >> >> ericindc wrote: >> >>> Say I have to Models,ProjectandCreator, related to each other such >>> that @project.creatoris valid. Creatorhas two fields, first_name >>> and last_name, for thecreator'sname. Assuming that I want a quick >>> way to display thecreator'sname as "last_name, first_name" inside >>> the view, which is the best approach (efficiency, the Rails way, etc.) >>> and why? >>> >>> Here are the approached I've come up with... >>> >>> A) Create a method in theCreatorclass called commified_name and use >>> @project.creator.commified_name in the view. This seems like a good >>> option. It's DRY and fits the rest of the mold for @project.xyz in >>> the view, but I think following MVC the model is not meant for >>> formatting, right? >>> >>> def commified_name >>> [self.last_name, self.first_name].join(', ') >>> end >>> >>> B) Do the join inside the view. Probably the worst of the options >>> since it allows for variations in how the name is displayed. >>> >>> C) Create a method in theCreatorHelper called commified_name and use >>> commified_name in the view. I believe this is the best answer since >>> formatting of information that goes in the View belongs in a Helper, >>> right? I just find that A feels more right to me. >>> >>> def commified_name >>> [...@project.creator.last_name, @project.creator.first_name].join(', >>> ') if @project >>> end >>> >>> If C (or A) is the best answer, is this a good way to accomplish what >>> I'm after. Thanks in advance. >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
