I am maintaining an application that has an account model which has many
payments. So the account model has a has_many relationship as shown
below:
class Account < ActiveRecord::Base
....
has_many :payments, :order => "created_at ASC" do
def charge(amount, paying_for)
Payment.charge(proxy_owner, amount, paying_for)
end
def commit(action, amount, paying_for)
Payment.commit(proxy_owner, action, amount, paying_for)
end
def gift(days = nil)
Payment.gift(proxy_owner, days)
end
end
.....
end
This may be an RoR 101 question, but why would someone define methods in
a has_many block? Can''t this be simply called as:
account_inst.payments.charge(amount, paying_for) for example?
I do not understand what is the benefit of defining (or proxying ) class
methods belonging to the many side of this relationship in this manner?
Thanks for your time.
Bharat
--
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
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 Jul 19, 10:14 pm, Bharat Ruparel <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I am maintaining an application that has an account model which has many > payments. So the account model has a has_many relationship as shown > below: > > class Account < ActiveRecord::Base > .... > has_many :payments, :order => "created_at ASC" do > def charge(amount, paying_for) > Payment.charge(proxy_owner, amount, paying_for) > end > > def commit(action, amount, paying_for) > Payment.commit(proxy_owner, action, amount, paying_for) > end > > def gift(days = nil) > Payment.gift(proxy_owner, days) > end > end > ..... > end > > This may be an RoR 101 question, but why would someone define methods in > a has_many block? Can''t this be simply called as: >It''s nicer to write some_account.payments.gift than it is to write Payment.gift(some_account). You get the association scoping for free which can help you avoid mistakes and make things more readable.> account_inst.payments.charge(amount, paying_for) for example?That is precisely what the association extension methods that have been defined allow you to do. One trick that is not well known enough is that if foo is a class method on payments then you can call account_inst.payments.foo() and it will call the class method foo except that everything will be scoped to only act on those payments belong to foo. This won''t work with the existing charge method since it requires an account as its first parameter. Fred> > I do not understand what is the benefit of defining (or proxying ) class > methods belonging to the many side of this relationship in this manner?> > Thanks for your time. > > Bharat > -- > Posted viahttp://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 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 -~----------~----~----~----~------~----~------~--~---
Thanks Fred. You wrote:
"This won''t work with the existing charge method since
it requires an account as its first parameter."
Was this an oversight since the first parameter of the existing charge
method is amount as shown below?
def charge(amount, paying_for)
Payment.charge(proxy_owner, amount, paying_for)
end
Nice explanation.
Regards,
Bharat
--~--~---------~--~----~------------~-------~--~----~
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 20 Jul 2008, at 17:35, Bharat wrote:> > Thanks Fred. You wrote: > > "This won''t work with the existing charge method since > it requires an account as its first parameter." > > Was this an oversight since the first parameter of the existing charge > method is amount as shown below?No - what i meant that the charge method you would get for free on the payments association (because of the existence of Payment.charge) wouldn''t do the write thing. Fred> > > def charge(amount, paying_for) > Payment.charge(proxy_owner, amount, paying_for) > end > > Nice explanation. > > Regards, > > Bharat > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---