Re: Implementing a credit-based system

Frederick Cheung
Fri, 01 Aug 2008 13:38:36 -0000

On 1 Aug 2008, at 14:24, CPerry wrote:

>
> 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.
>
I''m not even sure if there is a credits controller - you never
directly interact with them : you buy packages, and then you perform
uploads or other actions (which as a side effect use a credit).
The only thing I can think of is a page which showed you how many
credits you have or other audit traily types of information (but that
could easily just boil down to some text on the ''my account''
page).

Fred
> 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!
> >