I’m thinking about configuration screens for stuff at work.
Some setttings affect things that happen on our server.
Other settings affect things that happen on the clientside.
There is a conflict between building things ahead of time and crafting them to be very userfriendly, and building things dynamically on the fly and letting them be very flexible.

If a setting is going to only affect things on our server we want to avoid having to do a new client release just to let the client change them. After all, the client program doesn’t need new code. These kinds of settings it would be good to build user controls for dynamically. That way the client doesn’t need to download anything new when we expose new settings.

If a setting is going to affect only the client side, then we have to deliver new components to the client to consume those settings. In that case, we want to deliver the new functionality along with the settings and it makes sense to construct the controls beforehand so they are as userfriendly as possible.

One way might be to deliver a document on loading up configuration screens where you list the major pages of configuration. Each listing would describe either a usercontrol to load or a list of options to construct a control around. For dynamically created settings controls you would create checkboxes for booleans, textboxes for mapping strings, combo boxes for enums, etc, then slap them all in a flow layout or something.

Even if the coolness of dynamically created controls for server side settings is doable, is it worth it? If we are creating a way to deliver updates to users in the background, shouldn’t we just use that?