Jetengine - Chained or cascading selects with external values sources

elemazing commented 3 years ago

Apologies if there is away to to do the following, but I'm new to the Croco plugins and haven't found a way to do the following:

Say, for example, I wanted users to select a car, the Makes options could run to 80, then select a model for the chosen make (could be 10) and then a variant (say at least 5 for each model), that equates to 4,000 options. There is no way I can see to accomplish this in a sensible way.

It would be a fantastic feature to allow two or more selects to pre-filter/populate the next in a series to drill-down from a hierarchical set of values. The source could be a CSV or a hierarchical taxonomy. So, the first select in the chain could point to a parent node (could be the root or some node n levels deep) and the options for that dropdown would be then be the children of that node. Any subsequent and linked select could use the previously selected value as the parent node and display its child values. and so on. From a usability perspective this could also apply to checkbox and radio controls where the option count is small. In this way the 4,000 car options can be three simple selects, albeit the first for make would have 80 values which is not great for usability, but better than trying to split the makes down into smaller groups.

Using an external source for the values would mean the dynamic nature of keeping all options in one or more taxonomies make this data easy to manage and maintain. Also, things wouldn't break if some values were removed from the taxonomy because as this is input via the form in a one direction process, the CPT meta fields simply store whatever is added from the form.

Inevitably, where users can edit a CPT later and the some of options used originally to populate those controls no longer exists, and for whatever reason, you could take the view that these controls force the user to choose from the new set of options which might make sense if the options have been restructured or rationalised.

One option might be (I don't know if this is possible as I'm still experimenting) to use an intermediate field and an 'update' select field and the conditional logic setting. So it might work like this: the text meta fields for the example a car make, model and variant fields (read only) and only get populated when the chained selects all have values that are not "select ****" and the user has explicitly changes the value of a confirm select. In this way if values have been removed from the input control value source and the user can't find any thing better or more appropriate, then the user can chose to keep the old values.

Your current car: [BMW] [3 Series] [M3]

New car selection: [select make][V] [select model][V] [select variant][V] Apply change to new selection: [NO][V]

Apply change to new selection: [NO][V] would only appear when all dropdowns don't have 'select ****' values

I hope that makes sense. The car example probably is unlikely to have options removed, but only new ones added. But there are examples where this could happen: it might be quantities, no longer available things, period or time slots that are now in the past, etc.