Re: Implementing a credit-based system

CPerry
Fri, 01 Aug 2008 13:51:02 -0000

Yeah sorry! I meant 2 separate MODELS not controllers! That second cup
of coffee hasn''t quite kicked in yet.

--Cory

On Aug 1, 9:38 am, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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!
--~--~---------~--~----~------------~-------~--~----~
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