Dropdown select box choices not reloading - are they cached?

[kevinh]

We make use of RPGsp programs to fill dropdown choices using the choices URL property using something like

Code: Select all

js: "/icsui/selbr.pgm?COMPANY=" + get('UDCBD').substr(0, 1)

to call our RPGsp program SELBR passing it a company code from a field on the screen. Works great, except...

Occasionally a new value is added to our our files or we make a change to the RPGsp program as to what values to include or exclude. We have seen cases where if you have recently been in the program that uses the dropdown and then a new value is added to or deleted from the file that the dropdown populates from (using the RPGsp program,) or like I said the RPGsp program itself was changed, the change is not reflected in the dropdown list. I can log out of the browser, close the browser, etc. and go back in and still get the same results I was getting before the changes. I can have someone else go in and it may or may not be showing the change in their dropdown list.

Are the values being cached and if so is there a way to defeat that or force the values to reload? If not what could be causing this behaviour?

[Scott Klement]

Would something like this work for you?

Code: Select all

js: "/icsui/selbr.pgm?COMPANY=" + get('UDCBD').substr(0, 1) + "&md=" + Math.random()

It just adds a random number to the URL, which stops the browser from caching it (since it thinks each request is a new URL).

You could also turn off caching in the RPGsp program, too... but I think the random number approach is a little more reliable.

[kevinh]

Changing the URL in the display file's dropdown properties will be an undertaking with 100's of these across our applications. Changing our RPGsp programs would be more feasible, but I'm not familiar with that option, and am a little concerned with your comment about reliability. It's important these values are accurate as real-time values in the dropdowns. We use RGPsp programs opposed to the database driven option to provide more flexibility in maintenance and consistency among developers.

[Scott Klement]

If you want to try doing this on the server side, you should code this in your RPG program (this is free-format RPG code):

Code: Select all

        // Prevent page caching.
        RPGspSetHeader('Cache-Control: no-cache');
        RPGspSetHeader('Cache-Control: no-store');
        RPGspSetHeader('Expires: Mon, 01, Jan 1996 01:01:01 GMT');

These are sent to the browser, telling it not to cache the result, not to store the result in the cache, and also that if this is found in the cache, that cache entry should be considered expired (because it expired in 1996)

Over the years, bugs have been found in both browsers and HTTP proxies that have ignored these keywords. The browser bugs were fairly old, and all fixed now, but it's hard to predict exactly which HTTP proxies folks will use. That's why I say this is "less reliable". But, maybe it'll work in your environment?

Let me know if that'll work for you.

[kevinh]

Thanks for the insight.

We weighed our options of caching vs. no caching and having the most up-to-date values in the pulldowns. For the long term we are looking at the first option but with a twist. By passing the current session's job number on the URL to call the RPGsp program this will force the browser to reload the values the first time the URL is used and then it will be cached for the duration of that session as subsequent calls use that same job number. If a new dropdown value is added to the system then having the user log out and exit the UI session then start a new session will give them a new job number and force a new load of the values next time the call is made.

Please comment if you see any issues with that logic.

[Scott Klement]

It sounds good to me, and is a pretty neat idea... Let me know how it turns out.