Thanks, guys! That's a great help. I will most probably take you up on your offer of help! :) In the meantime, I have a couple of follow on questions:
1. What do you see the benefits of having a separate cart and order objects? 2. The Promotion classes were the logic takes place, are they also model classes or are they separate classes? Thanks again. Tom On Tue, Mar 30, 2010 at 2:00 AM, Richtermeister <nex...@gmail.com> wrote: > Hey Tom, > > I wrote the ecommerce part of www.skinmedica.com, which uses a quite > complex promotions setup and took some iterations to get it right. I'd > be happy to help. > > Our cart works similar to what Antoine said, where the shopping cart > is distinct from the final order, and mostly responsible for keeping > track of what's in it for calculating prices (shipping, tax, total, > etc. - the cart is actually composed of different independent service > classes to look up shipping, & tax via webservices). Generally we try > to keep the cart very limited in what it knows about the rest of the > system. > > The way the promotions work is that they're being applied to the cart > without the cart knowing much about what is happening. A promotion is > basically handed the entire cart and it gets to decide whether it > applies. It does that by using a separate class, a promotion > criterion, which depending on its type can apply different logic to > trigger whether it applies. For example, we have promotion criteria > that trigger based on: > - a certain cart subtotal > - whether a certain product is in the cart > - whether the customer is new > - etc. > Those are all different classes, extending a BasePromotionCriterion, > that are further customizable via parameters from an admin area. > > When the promotion applies, it gets to make changes to the cart. Those > changes, in turn, depend on the type of the promotion class. > We have promotions that: > - apply a cart discount > - apply a product discount > - add a free product > - make shipping free of charge > - etc. > > By combining criterion classes with promotions classes, and passing a > few parameters along, you can create virtually any combination of > promotions, and when you find limitations, you can simply add more > classes. Plus, this is fairly easy to administer. > > The hardest part is issues like precedence and mutual exclusivity. For > example, if a promotion applies a cart discount at a certain subtotal, > then that in turn can lower the subtotal. So, the system needs to be > smart enough not to remove the promotion again. Or, there are > szenarios where 2 free shipping promotions are applicable, but the > system should only apply one (usually the cheaper one, but that can > vary). > So, basically we apply weights to classes to figure out in which order > the promotions apply, and there is an override parameter that enables > each promotion to override others, for some manual finetuning. > Sorting that all out is a matter of a series of interesting loops with > callbacks that cost me a few sleepless nights :) > > Does that help? Let me know if you have any specific questions and I'd > be happy to help more. > Daniel > > > > On Mar 29, 5:56 pm, Tom Haskins-Vaughan <t...@templestreetmedia.com> > wrote: >> (sf1.4/Doctrine) >> >> Hi all, >> >> Let's say I'm developing an ecommerce solution. I have the following models: >> >> Order - takes a shopping cart all the way through to an actual order. >> >> OrderItem - link between the Order and one or more Products >> >> Product - a catalogue of products >> >> Promotion - e.g., buy one get one free, or 10% off item, buy these >> both for $10, etc >> >> The part I'm interested in is the promotions. I *could* do the logic >> in the Order model like so: >> >> $order = new Order(); >> ... >> $order->applyPromotion($promotion); >> >> But there is likely to be quite a lot of logic, depending on what kind >> of promotion it is (adding OrderItems, discounting Orders, etc), so my >> instinct was to create a PromotionManager class so for example: >> >> $promoManager = new PromotionManager(); >> $promoManager->appyPromotion($promotion, $order); >> >> Is this a better way to go, or am I causing myself needless abstraction? >> >> I know there's more than one way to skin a cat, but I'm trying hard to >> get to grips with the best way. >> >> Anyway, thanks in advance. >> >> Tom > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to symfony-users@googlegroups.com > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > > To unsubscribe from this group, send email to > symfony-users+unsubscribegooglegroups.com or reply to this email with the > words "REMOVE ME" as the subject. > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en To unsubscribe from this group, send email to symfony-users+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
