So like most of us, I have a marketing department who thinks everything is a simple matter of "point and click" and that changes can be made in under 30 seconds because OF COURSE it''s all done in Photoshop ;-) Obviously I''m trying to train (or would it be "educate"?) them to the reality of it all, but it''s a slow process. I''m interested in - conceptually - what some of you have seen in terms of best practices for accommodating complex e-commerce requirements. For example, let''s say I have a "product". This week the marketing department wants to run a special that says this product is 15% cheaper if another specific product is also in the user''s cart. Next week they want to change it to be $10 off if the user also buys a special "plan" (from a different model). Week 3 they want to require the purchase of a different product to be with said product - you get the idea. At any given time, I have AT MOST twelve hours notice on said changes. So far I''ve basically been telling them to piss off, but I really want to accommodate them if at all possible. The first (and current) iteration of this e-commerce project, I focused on what I called a "centralized purchasing paradigm", where the user started at any point in a non-linear process, added a product or a "plan" to their "cart", and all kinds of calculations and conditional logic made its way into the view due to deadlines enforced by (the commonly clueless) "management". This obviously is bad design, but unfortunately due to the way I had it all tied in together and the various "requirements", I didn''t really have much of a choice in the matter. Now I''m looking at a re-work on this codebase, from scratch, and thinking that maybe it''s best to separate products/sales by type, and force a pseudo-linear process, segmenting things out, because I don''t know how to accommodate the strange scenarios above without writing fresh code logic each and every time. At least this way, I''m able to make changes to one type of product without affecting the others (separating them into multiple controllers and adding methods only on specific models). This would theoretically result in controllers/routes like phones/ blackberry/buy/1 or phones/samsung/view/3 or plans/traditional/buy/4 and with the combination of plan 4 the customer MUST have feature ID 3 in their cart at an additional price, but if the plan is ID 2 they don''t have to have it, if the plan ID is 5 they *can''t* have it, etc. What''s the best (most modular/OOP) way to go about this? I really want to give our marketing department the agility that they''re asking for, but I just don''t know any good design patterns to accomplish this for a one-person (me) design, development, and web management "team" with multiple projects. Does anyone have any input on better e-commerce design patterns, or can you point me to some trusted/realistic (theoretical, but with concrete examples) on the matter? Thank you very much. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
maybe use opensource can resole your request. fat-free-crm in github.com 2009/11/25 Phoenix Rising <polarisrising-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> So like most of us, I have a marketing department who thinks > everything is a simple matter of "point and click" and that changes > can be made in under 30 seconds because OF COURSE it''s all done in > Photoshop ;-) Obviously I''m trying to train (or would it be > "educate"?) them to the reality of it all, but it''s a slow process. > > >-- tommy xiao E-mail: xiaods(AT)gmail.com -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I am thinking along the same lines and wanting to abstract my pricing module into a Rules engine. Here is one example: http://grails.org/Drools+Plugin The basic ideas is that your specify Rules which fire against a set of data (objects) and then out comes a result. It is not "programming" just like spreadsheets are not programming ;-) Redhat/Jboss have an open source BRMS (Business Rules Management System) which gives you a whole lot of extras such as rule authoring tools but it is all in Java. There is a ton of material at http://www.jboss.com/products/platforms/brms/ such as whitepapers, webinars etc. I haven''t quite worked out the architecture to get an Rails app running in Passenger to talk to it. Might it be worthwhile to run on a J2EE server using Jruby? http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-ruby.html As you can guess I haven''t gone down this route yet but it is something that I am seriously considering. I would be interested in any thoughts from anyone who has moved in this direction. O. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Ignore the link to grails. I shouldn''t have pasted that (I''m becoming over-reliant on Google). However, check this one out: http://wiki.github.com/mattup/ruleby -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Thanks for the link! Ruleby looks pretty awesome. I never thought of a rule-based approach, but that makes a lot of sense to take it from that perspective. I''m a bit curious as to how the rete algorithm comes into play, so I''ll have to do some reading up on what it is and how it works. Anyone else know of other approaches to the same issue? Want to share? :) On Nov 25, 2:19 am, icke <owain.mcgu...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Ignore the link to grails. I shouldn''t have pasted that (I''m becoming > over-reliant on Google). However, check this one out:http://wiki.github.com/mattup/ruleby-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.