Samuel,
I agree that a rules engine would bring unnecessary complexity the the users and I am considering a simpler approach. I am going to take a deeper look, but it looks like the "rules" would be something as simple as "if option X is 'a', option Y can't be 'b' or 'c'" or "if option X is 'a', option Y must be 'd'". Each valid configuration has a corresponding part number. There's no need to generate quotes for products or shipping. This website will be just a catalog. Cheers, Flavio On 09/10/2014, at 15:46, Samuel Pelletier <[email protected]> wrote: > Flavio, > > You did not specified if the system is intended to select an existing product > from a known list of to create a custom order that should be valid. Creating > a system to select a product from an existing list is easy. Having built a > system to order and quote price for kitchen cabinet doors from multiple > manufacturers, I can tell you the problem can be very hard for full custom > ordering system. > > You may check > http://www.richelieu.com/ca/en/category/doors-drawers-wood-components/tailor-made-cabinet-door-drawer-fronts/1000128 > to see the result. > > Rules engine works when the validation is rule based, sometime, rules does > not exists and they may be very hard to write, especially for non tech > people. If the number of possibilities is small, a exhaustive list of valid > possibilities can be created, you can use an Excel file as a way to manage > the list. If your configuration is use to build a sku number or if the > options can be described in a similar way, you may also use a valid pattern > list system. I know some people that use rule bases systems for these but the > maintenance of the rules is hard, I personally never used a rules engine. > > The worst thing is that a valid configuration is often just the beginning, > you need to put a price on it after... and maybe compute delivery costs. > > Samuel > > > Le 2014-10-07 à 02:47, Pascal Robert <[email protected]> a écrit : > >> +1 for the rules engine. >> >> Another option would be to write logic as dictionaries stored and serialized >> in the database. At a previous job, we had that to store logic for a survey >> app (to force questions to be answered if you answered X for a previous >> question, etc.) >> >>> Have you considered a business rules engine? Have a look at some of these >>> http://java-source.net/open-source/rule-engines >>> >>> Would a rules engine solve your problem? >>> >>> Chuck >>> >>> >>> On 2014-10-06, 1:57 PM, "Flavio Donadio" wrote: >>> >>> On 06/10/2014, at 16:51, Chuck Hill <[email protected]> wrote: >>> >>> I think Flavio’s question was more of how to model this so that the >>> configurations were not hard-coded in Java. I don’t have an immediate >>> answer, but it is an interesting modelling problem. >>> Chuck >>> >>> Chuck is right. I have something more into the lines: >>> >>> Product <--->> ProductOption <<---> Option <--->> OptionValue >>> >>> ... where Option is something like "Display Type" and OptionValue is >>> something like "Monochrome". And ProductOption is just a proxy table for >>> the many-to-many relationship. >>> >>> Maybe I should have two more relationships: >>> >>> OptionValue <--->> OptionRequire >>> OptionValue <--->> OptionExclude >>> >>> An AJAX interface would be preferable, so the user gets an error message >>> when changing the selections, not when the application saves the context... >>> >>> >>> Cheers, >>> Flavio >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >>> >>> This email sent to [email protected] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >> >> This email sent to [email protected] > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
