Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: LifeinAsia
I accepted this in an advisory capacity, no agreements are signed or promises were made, but it still sticks in my craw that it "can't be done."
Task: Move existing site with a multidimensional custom ordering system to a linear standard shopping cart product.
Cart product: The cart has one page per product with unlimited options, but there are no dependent option or multiple page capabilities, which becomes important. We can add limited scripting and modify templates, but have no control over form element object names and cannot modify the cart source files.
Basically, take my tools away and ask me to build a house.
Existing site: The closest generic comparison I can come up with is an online computer builder, like Dell or something. You select an item from a series of 6 groups. Depending on what group you select, the first set of options differ across the board, so the first option is actually 6 groups of options.
On selection of the first option, some of the subsequent options now change, this is what I meant by dependent options. Continue this process until all options are selected, which also differs slightly. Some have 6 options, some have 3, some have 1.
It gets more complex - the options are strictly visual, you have to see a picture of each to understand what the options are; they have to all be on a page to compare them. This applies for all selections.
More: for each of the 6 groups above, there can be multiple instances of these groups in a single order item. Using the computer ordering analogy, it would be like two computers combined into a single computer, with the options of each unique to that sub-item. Or maybe, the "single item" is the purchase of a small office network, with each station customized differently. There can be between 1-6 "sub items" for each product. The idea to break these into six separate product items was proposed, for various reasons it will not work.
Now. Take all that . . . and put it into what most of us know as a stock order form, with custom select lists, text boxes, etc.
Deadline is . . . well it's passed, actually. But call it two weeks.
<option value="16:::::option value1">
where the blank options are placeholders for values that may or may not exist. There is no way I'll know what those are in advance.
My opinion, especially after exploring this and knowing the particulars, is that given a couple months and 100K gallons of coffee, we might bend JS/jQuery to our will and get something to work, but that would be no substitute for doing it right - custom coding it in an environment where we can control the server programming.
I'd be interested in any possible ideas, relevant or otherwise, in all my years of doing this I've never once said "impossible." This is a first for me.
1) Decouple the catalog / visualisation app from the cart/order process. You will end up with a bespoke catalog with all your business rules that are unique to you, but a more manageble robust odering system that can only be accessed by your bespoke app.
2) Find a cart with something like a BOM explosion or "Product Kit" feature of the M$ CRM Product entity.
3) More coffee & contemplation., You really dont want to rush a decision you will regret here..or worse..get part way through and realise its the wrong horse.
Personally I wouldnt touch client side code, unless I held the contract for maintaining it and the client had deep pockets :)
You really dont want to rush a decision you will regret here
This is actually part of the problem, I think. This came down in such a way that, through no real fault of the client, it was forced upon them on the cusp of the holiday season, and they are pushed to get something in place quick. I say stick with what you have and just fix anything you don't like about it, do this when you have time.
It's also still a square peg, and requires special handling that most linear carts can't do. This is why it's custom. :-)