Hey Antoine, yeah, the weight is helpful, because it allows you to quickly declare certain promotions "king".. for example, our subtotal promotion has a weight of 10, where other promotions range around 1-5 so far, so that it always gets applied last. As promotions get more similar, the weight calculations get narrower, and sometimes you get unexpected results, but at least you're giving your cart a simple mechanism to decide the order, and you can leave determining the actual weights at runtime to some other mechanism. This keeps the voodoo to a confined space in the system ;)
Daniel On Mar 30, 1:09 pm, "Antoine S." <antoine.spodobal...@gmail.com> wrote: > Hi, > > Cool Daniel, I am happy that you confirm this choice. > For multi promotion, the weight is a good idea. > I was thinking of a config file, to say if a promotion are combinable > with the other (matrix). But in fact a matrix with weight would be > perfect.. > > 1. First you need to store the cart in the user session : bad idea > with a database object > Then, an order stays an order (model of the database) > The shopping cart is more interactive and functional (add, remove, > promotion, calcultation..) > > 2. For me, they are model class. I use PromotionTable to find the > discount. > Then (I have not done this yet) but each promotion could be a class > (as Daniel have done). > > On Mar 31, 2:09 am, Tom Haskins-Vaughan <t...@templestreetmedia.com> > wrote: > > > 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 ofwww.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
