Dropdowns with 10 thousand possible values and sequence-important dropdowns vs. graceful degredation

Background

I have this form that uses javascript exclusively to search through ~5k entries (suppliers) and populate a select dropdown from them (factories, ~10k entries). Right now, it's a javascript-required form. I'd like to make it so that javascript errors no longer render the fo开发者_如何学编程rm unusable, but the number of entries and the sequential nature of the entries leave me without a idiomatic way to provide just a basic html version.

The Issues

Sequential/hierarchical dropdowns

An example dropdown where sequence is important: http://www.javascriptkit.com/javatutors/selectcontent2.shtml

So that shows "filtering" of sequential/hierarchical dropdown content, where the selections in the second City dropdown get filtered based on the selections in the first Country dropdown. But take away the javascript, and it could instantly become a mess. Madrid in the USA? Berlin in France? The sequence becomes corrupted.

Dropdowns that have huge numbers of options

If you have a select dropdown with 10k possible options, it's pretty easy to filter/search through them with javascript. Dealing with those options without javacript, on the other hand, is much more difficult.

How do you provide your users with all of the possibilities when just loading all the options them all would blow up their browser?

Possible Solutions

Sequential/Hierarchical Select boxes:

• Server-side 2-part forms.
• ?Select option groups?
• ???

Selects with huge numbers of options:

• Server-side 2-part search forms.
• Server-side text search matching of entry names.
• ???

Simple links to resourceful solutions welcome.

The only solution that I can think of is to use a form submit each time you need to narrow down your results. You start off by showing a page to select a supplier's country. That submits, and returns a page that shows the selected country as text and now has a drop-down to select the next field, like cities. That way, the server can do the filtering at each level.

Here's a JSP example:

<c:choose>
    <c:when test="${empty country}">
        Country: 
        <form>
            <select>
                <option value="USA">America</option>
                <option value="DEU">Germany</option>
                <%-- ... --%>
            </select>
        </form>
    </c:when>
    <c:otherwise>
        Country: ${country} 
        <c:choose>
            <c:when test="${empty city}">
                <input type="submit" value="Change" />   <%-- Button to change the previous value --%>

                <%-- your form for choosing a supplier's city --%>                    
            </c:when>
            <c:otherwise>
                <%-- continue filtering until you have all of the data --%>
            </c:otherwise>
        </c:choose>

    </c:otherwise>
<c:choose>

When you select a country, the form submits. Your server processes the country, returns the same page with the country field value and a list of possible cities for your next drop-down. Doing it like this allows you to rely only on form submits (rather than JavaScript) to filter data sequentially. Your server would be responsible for keeping track of how far along the user is. The obvious downfall of this solution is that your JSP would be pretty messy, with all of the nested <c:choose> blocks.

You might also try a hybrid solution: when the page loads, find out if your JavaScript has loaded. If so, replace your submission forms with plain HTML that has AJAX behind it to populate the next set of options. That way, your page doesn't have to refresh a bunch of times when the JavaScript does load, but will still be functional if the JavaScript doesn't load. Just a thought.