I have a problem with an online catalogue for a website I maintain. The catalogue has lots of options but is small and if the user reads it properly straight forward but users being what they are they do not read the options properly or possibly do not understand them.
Currently the user picks out what they want and put all the parts into an order form which the site owner examins and if there are any problems he contacts the user. This works but the site owner wants to reduce the time he spends sorting out these problems.
To get an idea of my problem:
You can buy a full kit
You can specify two motors which means you pay extra for the second motor and drive.
You can then have suspension which means you get a rebate for the fixed axel but then pay extra for the suspension
It is a bit like a pyramid with the kit at the top and starts spreading out depending on the options specified
You can also buy as many of the parts you want and either source elsewhere or make them.
I suppose I could build loads of kits with all the different options or I could do lots of if statements ( I am building the site in php )
I think the way to go is with the prices in a database but can anyone suggest some ideas or have recomendations on which way to go with this.
Note: Sometimes if you have one option you also have to have another e.g. If you have two motors you also need two drive wheels and not one drive wheel and one freewheel.
I suppose I may have to go the Ajax route?
I have just noticed there is another complication as you can buy kits like a front suspension kit which contain multiple parts and the options relate to this as well!
It might give more of an idea if I link a pdf price list
Consider making a PARTS objects ( all objects will reflect a table in your DB). This would probably contain properties such as
partID
price
description
image
availability
maybe even compatibility
ALSO an abstract class for KITS
which contains a list of PART OBJECTS
and a concrete class for KITS ( based on the abstract)
which has function for pricing based on the sum of the parts, ect…
you can the have an ORDER object which builds and stores a list of PARTS and/or KITS INSTANCES and from that totals up the cost, calculates discounts, etc.
PART->KIT->ORDER
Aside from making your code cleaner this style of thinking will make it scalable as well.
I have not used classes and for what I normally do it is not required; so I do not really understand what you are saying I will see if I can find any more information on “abstract class” etc.
Thinking about the small kits there is no price difference to the sum of the parts in the kit; it just makes it simpler for the user to tick on one box instead of six boxes.
I quickly entered the prices, item, description/notes and whether the item has VAT into a database last night and will be able to try things out with the real data which sometimes helps decide on a method.
I have eight models to sort out prices for so something which will work on every model would be good and thinking about it some parts are used on two or more models.
So if I get you right the customer is building a custom product made of several components?
How about trying something like PC system builders use, eg http://pcspecialist.co.uk/pcs/ - you pick a start point, then go through various options choosing whichever you want?
So if I get you right the customer is building a custom product made of several components?
Yes that is the basic method but the customer can buy anything from the whole kit to one or two parts.
If they buy a whole kit they can also have the options which means getting a refund on the standard part and then paying for the option or it can be seen as paying a suppliment.
I think I need to sit down tonight and make myself a diagram of how it actually works and then maybe persuade the site owner to do it in a slightly different way.
I think this thread is premature and should be moved to the Database Forum. No doubt some database guru will be able to suggest a table schema which will help with your queries,
Initially I’m thinking of basically a table->model and table->unique-parts. The model query will generate unique-parts with name, description, price, quantity, etc each with a checkbox. Input button builds an invoice…
I was looking more for a method at the moment and was going to look into the database later. I suppose its a chicken and egg situation - do I start with the database or sort out the method to achieve what I want and do the database later.
Done but this looks to straight forward and I am sure there will be problems!
The method I am looking at now is:
Parts
Put all the parts in one table as some parts are common to the eight models
id - Item - notes - price - VAT due - indicate if an option
Model
Need a page for full kits and options with a seperate page for parts and options.
Both pages will have kits displayed in seperate divisions as individual parts ( standard and options )
Full kit page
List of all standard parts checked
options unchecked
Kits page + purchase individual items
The user will need to select each part in the kit and options could be a different colour.
List of parts unchecked
options unchecked
At the end of each page there will be an area for the users details
When the user presses submit the details are sent to a checking page where their details and any options are checked with if statments.
The price will be adjusted depending if any uption selected again with if statments.
If there is a problem an error is displayed and the user is instructed to go back and fix the error.
Resubmit the page after mods and confirmation of order displayed the submit and invoice created and emails sent.
This means I will need:
A table for the parts
A table for each model linked to the parts in that model
A tool tip would be good so if the user puts their mouse over the option it could tell them what they need to remove for the option.
Note: I knew I had forgotten something and that is how to separate the kit items!
I have been having a test and think it may be better to have the parts list broken down with the parts for each kit ( e.g wheels ) in their own tables.
This means more database queries but it makes the setup of the divs simpler.
A stumbling block - With the prices in one big table all I needed was one table for each model picking out the used item from the price table.
Model1 - item price
Model2 - item price
But with the parts table being split into about five smaller kit tables I will then need five more tables for each model to pick out the items from all of the kit tables!
Model1_kit1 - kit1 item price
Model1_kit2 - kit2 item price
Right the database part is working now:
Table containing the items with a column for the kit
Table for each model listing the ID from the price table
Database call for each kit on each model page
Well I have something working but the site owner is not impressed
He wants a build a model type site where you pick the model > pick the drive > pick the control etc. There could be 30 or more pages unless I do something in JavaScript?
I thought of using a dropdown list for the options but you can not style the option box very well and some of descriptions are so long they go off the page.
I can not find any ready made "Build " type code to use or modify - he is also not impressed with the zencart demo I set up.
I will see if I can find any more information on “abstract class” etc.
