New York wrote:It's a good thought, but I wonder what the impact would be on performance if the core has to call the 'chain' of plugins looking for first to return a price (e.g. possibly in reverse order of your list "'simple price','tier price', 'pricing by attribute combination','customer enters price', etc").
Hey New York,
I don't think I would write the engine mapping as a many to one. It would make more sense to have a one to one mapping because in each of the scenario's you don't really need to have multiples. I think in the end it may actually make the pricing calculations faster because each engine could be fine tuned for it's specific purpose. All of the current pricing options could easily be written and used this way.
I would probably store the mappings similarly to how scheduled tasks are stored, a table of installed price engine types and the product table would contain the id of the price engine. Then all of the setup, logic, admin configuration screens, etc could be stored as separate plugins. This would also let the end user install just the engines they need for their product line.