Solve updateSelectInput bug in IE 11.0

[bborgesr]

Fixes #1257

[wch]

Are there any drawbacks to using cache: false?

[jcheng5]

Doesn't seem like there's much downside. It adds some crud to the URL to bust the cache. I guess if the data hasn't changed and you hit the URL several times, it might be making unnecessary requests?

Our other option is to do this on the server side--add the cache-busting parameter to the registerDataObj method that forms the URL that is sent to the client. The benefits of this are 1) this problem will be solved for all clients--nobody else need remember set cache:false, and 2) you'd actually get some desirable caching behavior (i.e. you wouldn't have the problem in the previous paragraph).

[bborgesr]

Ok, changed it to your suggestion, Joe. It seems to work equally well. I basically added a pseudoparam that sticks in the timestamp in the URL, tricking the browser into thinking that it's a new page so caching doesn't occur. This is how I think it's done by ajax anyway: " It works by appending "_={timestamp}" to the GET parameters." (http://api.jquery.com/jquery.ajax/). What do you think?

[jcheng5]

Why not just delete this?

[bborgesr]

Oh, no reason, just because I wasn't sure this was really better than the alternative, so I was just experimenting with it, pending feedback. But it seems like there's no objections, so I'll get rid of it.