Re: Data model suggestions...
Re: Data model suggestions...
- Subject: Re: Data model suggestions...
- From: Flavio Donadio <email@hidden>
- Date: Fri, 10 Oct 2014 16:11:47 -0300
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@hidden> 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@hidden> 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@hidden> 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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden