Re: Implementing a credit-based system

CPerry
Fri, 01 Aug 2008 13:24:43 -0000

Frederick, Thanks for the clarification. I see what you are saying
with making sure there is as little logic as possible in the
controllers.

I also see what you are saying with having 2 separate controllers (1
for the credits and 1 for the packages). I had not thought about it
that way before, but that does seem to make more sense to me.

For some reason, I keep thinking that I have to have as few models and
controllers as possible, when I think I should be concentrating more
on building it the way it makes the most sense.

--Cory

On Aug 1, 8:55 am, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 1 Aug 2008, at 13:45, CPerry wrote:
>
>
>
>
>
> > Hey all, fairly new to Rails here and I am currently building my first
> > Rails app.
>
> > I am building an app that will require users to purchase credits in
> > order to post items on the site. These credits will be purchased in
> > blocks of credits like 5, 10, 20, etc. (similar to istockphoto.com).
>
> > Here is how I picture setting up the credits in my app.
>
> > Credits Model - This model would determine the different credit
> > packages (5,10,20) along with the price of each credit package.
>
> > This model would "belong to" User and the User "has
many" Credits,
> > right?
>
> Part of this depends on your requirements, but you could easily have 2
> models:
> Credit (belongs_to user, and user has many credits). 1 for each one
> purchased and tracks stuff like if it should expire, what it was used
> for, etc...
>
> Another model which handles whatever packages people can purchase.
>
> > I then assume that the controller for my credits is where I would
> > handle the logic of adding credits to the user accounts, making sure
> > the credit is deducted when they list an item, and keeping track of
> > how many credits a user has at any given time. I also assume that as
> > credits are purchased, and the user needs to be emailed notification
> > of that purchase, that logic would also live in this same controller,
> > right?
>
> I would have very very little in the controller, probably as simple as
>
> def purchase
>    @package = Package.find params[:id]
>    current_user.purchase @package
> end
>
> Similarly, at the point where the user uploads some content, i doubt
> I''d do much more than call a method on the user (and the logic of

> removing credits etc... would live there).
>
> You might want to do some of the emaily stuff via an observer.
> There''s a saying out there which is a good rule of thumb:
''skinny
> controllers, fat models''
>
> Fred
>
> > Am I on the right track here as far as mapping out what goes where? I
> > am really loving Rails so far, I am just having a bit of a hard time
> > wrapping my head around where logic goes and what handles what and how
> > they all tie in together!
>
> > I appreciate any help or feedback that you guys can give me! Thanks!
--~--~---------~--~----~------------~-------~--~----~
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