Rails - Jan 2009 - Customizing Model Data -- Inside Model or View or Helper?

Say I have to Models, Project and Creator, related to each other such
that @project.creator is valid.  Creator has two fields, first_name
and last_name, for the creator''s name.  Assuming that I want a quick
way to display the creator''s name 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 the Creator class 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 the Creator Helper 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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, Project and Creator, related to each other such
> that @project.creator is valid.  Creator has two fields, first_name
> and last_name, for the creator''s name.  Assuming that I want a
quick
> way to display the creator''s name 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 the Creator class 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 the Creator Helper 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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...-JfOZzmRpUsu/uRbK1X5IkLHvCTsVnGdA@public.gmane.org>
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Oops, I meant A (in the Model) is the best answer, not C.

On Jan 31, 9:42 am, ericindc
<ericmilf...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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...-JfOZzmRpUsu/uRbK1X5IkLHvCTsVnGdA@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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...-JfOZzmRpUsu/uRbK1X5IkLHvCTsVnGdA@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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.
I prefer to say that like: Put the code where it''s easiest to test.

Models are easier to test than controllers, so put the most business logic 
there. Views are hardest to test, so put lots of untestable art there!


--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Agreed its easier to test models, or at least I find it easier. I''d say
that its a fortunate side effect though, rather than a reason to test in 
a certain way. Although I guess if it really is too hard to test any 
part of your app then you''re probably trying to solve the problem in
the
wrong way. I never test my views to be honest, it seems that its going 
just a step too far and it tends to be fairly fragile at that.

RobL


 > I prefer to say that like: Put the code where it''s easiest to
test.
 > Models are easier to test than controllers, so put the most business 
logic there. Views are hardest to test, so put lots of untestable art there!



--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for the replies, fellas.  I''ve moved the code into my Model.
Thanks again.

On Jan 31, 11:33 am, Rob Lacey
<r...-JfOZzmRpUsu/uRbK1X5IkLHvCTsVnGdA@public.gmane.org>
wrote:
> Agreed its easier to test models, or at least I find it easier.
I''d say
> that its a fortunate side effect though, rather than a reason to test in
> a certain way. Although I guess if it really is too hard to test any
> part of your app then you''re probably trying to solve the problem
in the
> wrong way. I never test my views to be honest, it seems that its going
> just a step too far and it tends to be fairly fragile at that.
>
> RobL
>
>  > I prefer to say that like: Put the code where it''s easiest
to test.
>  > Models are easier to test than controllers, so put the most business
> logic there. Views are hardest to test, so put lots of untestable art
there!
--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Friday 30 January 2009 09:31 pm, ericindc wrote:
> commified_name 
Off the point, but before we allow a word like commified to escape into 
the wild (see usage in next post by Rob Lacey), we spell it commafied 
instead--there is a slightly greater chance of guessing its intended 
meaning.

Randy Kramer
-- 
I didn''t have time to write a short letter, so I created a video 
instead.--with apologies to Cicero, et.al.

--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sat, Jan 31, 2009 at 10:06 AM, Randy Kramer
<rhkramer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Off the point, but before we allow a word like commified to escape into
> the wild (see usage in next post by Rob Lacey), we spell it commafied
> instead--there is a slightly greater chance of guessing its intended
> meaning.
And even greater:  `acts_like_last_name_comma_first_name`  :-)

-- 
Hassan Schroeder ------------------------
hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---