Re: Implementing a credit-based system

Tim Gossett
Fri, 01 Aug 2008 18:15:43 -0000

On Fri, Aug 1, 2008 at 8:45 AM, CPerry
<cory-jEJZ73ctDLTqlBn2x/YWAg@public.gmane.org> 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.


Is a Credits model necessary? Would it be easier to have a credits attribute
(int) on the User model, and increment/decrement accordingly?


> This model would "belong to" User and the User "has
many" Credits,
> right?
>
> 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?


How about a Package model (which would hold the price for the package,
number of credits, and any other attributes you''d like). Then define a
method on the User model called "apply_credits(number)" which takes
the
number of credits to apply as an argument. Then, when they purchase the
package, do "@user.apply_credits(@package.num_credits)" (in the
controller
that''s handling the purchase) to increment the credits.

You may want to watch a few Railscasts (
http://railscasts.com/episodes/archive), especially #4 - Move Find into
Model. It''s a good idea to have fat models and skinny controllers--move
all
your complex logic to the model and keep the controller terse.

--
Tim