But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so it doesn't need to fire that call again.
And of course you want that calculation to happen on the client, for 2 reasons:
1. In sparse-use sets (like pick a state, then pick a city, then pick a district) you will only really need to use 10% of the data, you can save a ton on bandwidth here.
2. In situations where the render patterns get complicated, it's really just a PRESENTATION issue. The server may validate that you're not using noncompatible dropdowns, but it otherwise should not care what happens in the browser related to that.
