How to implement dynamic selection from form to results

[dennis-fedco]

I am looking for a high-level (but detailed) conceptual technique on making dynamic selection via a web page, where selection options are stored for later use in a database.

 

Scenario:  I have various options for assembling a custom-made product.  I can select demands that the product must satisfy via a form, and submit my selection to the server.

 

It then runs an algorithm to match my selections to the possible products that can be built to satisfy the demands.  There can be anywhere from 0 (not possible to build product), to 1 to 200 various ways to build possible products that match my selection.   I will call original user selection as "original selection" and the 200+ options as "options".

 

Right now there is an existing system in place which is a hideous mess of JSON, JS, HTML, and PHP.  Maybe the technologies are the way to solve my problem, but the way it is solved now is hard to maintain.  I don't know if there is a better way.  Right now, all options are being pre-generated via PHP, and are encoded into JSON, then JSON is read by JS, which drives the dynamic selection of options.  Then when an option is saved, entire list of options is saved along with it...  Then, when we want to know which original selection was made, we read back all the options from the database and the index of the one we actually need.  They are in JSON, we decode that, and then we have what we went.  It sounds convoluted to me, and I would like to simplify it a lot, potentially rewriting it.  How?

 

Basically I want this end-user scenario: 

1.  User makes selections via form, submit

2.  User is presented with all options.  Since there are a lot of options we want user to be able to navigate through them in real time.  JS may be of value here, rather than doing new page loads, including AJAX page loads.

3.  User saves their selection, and results from page are either displayed back to the user or are saved in DB.

 

 

[dennis-fedco]

in other words, how does one implement something like this ..  on a high level.  I will ask for details if I need more.

 

so first, I have a form, then I submit the form, generate my options via PHP, but ... how do I display them in an iterable form?  How do I pass the data from PHP to JS?  Do I load everything up ahead of time and have some huge JS object in the browser to iterate about as user presses left/right arrows?  How do I go about that?

 

[ginerjm]

You could probably simplify your task a lot if you provided an initial set of dropdowns that the user clicks on to begin his process.  Once he submits the form you build a new form with those selections displayed at the top and the necessary set of just-built dropdowns from which he can then refine his choices.  Upon submission of that form you could then display a page that lays out for the user just exactly what he chose and seek approval of it and then post the data to your db.

 

To do it actively, ie, without a submission, you would have to either use ajax to interact with the server behind the scenes, or use js to populate dynamic dropdowns from a large set of pre-loaded data.  Depending upon the needs of your system and users, my idea will save you a lot of headaches and time since you won't have to load a lot of data via json and your queries will be more straight forward and smaller

[Psycho]

Whether the current solution is too convoluted or not is hard to say. If there are requirements to have some things "dynamically" change on the web page without a submission and/or refresh then you will need to have some integration between PHP and JavaScript. And the preferred method of exchanging data between the two is JSON. But, it could still be more complicated than it needs to be.

 

It's really hard to provide much guidance without some knowledge of how the variable configuration options work. But. I have some experience with variable products that may help.

 

I would start with a table of "options". This would just contain basic details such as the name of the option, default value, and the "type". The type would correlate to field types such as text, radio button group, check box, select list, etc. Depending on the type, they may require additional details. So, for the "select" types there would be a supporting table where there would be entries for the possible values for the select list. Likewise, a radio group would have something similar. A text type may have a supporting table with data such as max length (or whatever variable information about the options that you feel is necessary).

 

You can then use the options table and the associated option details table to build your forms. If you are building a form from scratch, use the default values defined for each option. If you are recreating a form, pull the saved data and build a form using those values to populate the form. I would create a function for each field type for the purpose of creating the output. So, a function for a select list would take parameters for things such as the name of the field, an array of the possible value and the selected value. Either pass the default value or the saved value as the selected value. The function would create the select list and set the appropriate value.

 

Now, if you want the user to be able to interact with the form and have content update dynamically without a page submission, then you do need to use ajax. It's typically considered a better approach to pass data back and forth and have JavaScript act upon that data. But, it may be easier to have PHP generate the HTML and pass it to the JavaScript to update the page. But, even if you were to just pass JSON to the JavaScript code to create the dynamic content, once it is done - it is done. If done properly, you can add/edit/delete options to your hearts content in the database and it should require no reaction in the code.

[dennis-fedco]

ginerjm:  not sure if I can see the application of your idea to my project. 

 

In my case user selects things like various hydraulic requirements in order to build a pump that can handle the liquid pressure that is going to be pumped through it.  So from the original selections that the user makes, the algorithm computes various possible pumps that can be built.  That includes combinations of the pumps along with other devices that can be attached to pumps, and the graphs of various efficiency measures and throughput and other metrics of the product combination.  User then looks for what they need - it can be efficiency, it can be throughput, it can be something else, depending on what they want maximized.  Or sometimes the best option for them is not maximixing one thing, but a compromise on price or other things.  So looking at options gives them a better view of the possibilities space.

 

I suppose that in theory users can indeed have a secondary menu (or actually put it on the first) saying "hey I want higher efficiency so give me that", or the like which can help narrow down the choices.  It will still not eliminate them down to one.  I am not sure however that this will work for me .. this is a custom shop and the culture seems to be "give user all options and let the user decide".  In other words, while it can be narrowed down, I will still need to load or pre-load options.  There is no way to return one anyway as we want more than one option for sales purposes and such.

Edited July 8, 2014 by dennis-fedco

[ginerjm]

I'm sure my approach is as good as any and that it meets your goals.  It is just a question of whether you NEED immediacy in the way the dropdowns react or not.  Using my approach, as each level of drill-down occurs the client waits for the form submission and server response to occur in order to provide the next level of choices.  Using JS and AJAX there is a similar cycle that just happens to occur without the screen refresh, just updates to screen elements that may or may not have been hidden.  Using all JS and JSON to build things you get a more immediate response at the expense of your time and effort in developing it.  It is all up to you.

[Psycho]

Maybe I misunderstood some of your requirements.

 

As far as giving options for varying price, efficiency etc. you would have to add additional details about the "parts" and how they are used in the calculation. Assuming the parts already have a price associated with them. So, you would want some way to use an existing value (e.g. diameter) or assign a score to the parts for any other attributes you want to compare - such as efficiency or throughput. This really take a detailed analysis of the possible parts and how they affect the formula in order to configure correctly. Plus, I assume there are some dependencies between parts. For example, you can't just switch out a 2in valuve for a 4in valve on the same pump without necessitating other changes. So, you may have to have an option to increase the diameter for all parts.

 

Here's an example of how the problem could be approached. Let's take the formula for flow rate:

 

Flow Rate = 1/4 X π X (pipe diameter)^2 X velocity

 

You could show options for greater efficiency based on parts with a higher diameter. "How" that option is displayed to the user is inconsequential. It should "just work". I suspect it would take a lot of time, analysis and coding to create the right framework. But, if done correctly, it shouldn't take any code changes to maintain.