Preventing loading in cached SmartGWT .js files when a new SmartGWT version is being used?

[user316]

Currently in the index.html file, we have this:

<script src="beer/sc/modules-debug/ISC_Core.js"></script>
<script src="beer/sc/modules-debug/ISC_Foundation.js"></script>
<script src="beer/sc/modules-debug/ISC_Containers.js"></script>
<script src="beer/sc/modules-debug/ISC_Grids.js"></script>
<script src="beer/sc/modules-debug/ISC_Forms.js"></script>
<script src="beer/sc/modules-debug/ISC_Calendar.js"></script>
<script src="beer/sc/modules-debug/ISC_DataBinding.js"></script>
<script src="beer/sc/modules-debug/ISC_Drawing.js"></script>
<script src="beer/sc/modules-debug/ISC_Charts.js"></script>
<script src="beer/sc/modules-debug/ISC_RichTextEditor.js"></script>

These files are cached by the browser, which works perfectly well until we update the SmartGWT version. Is there an easy way to instruct the browser to load in all these files from the server, rather than the cache, only when we deploy a new SmartGWT version? For example something like loading in beer/sc/modules-debug/ISC_RichTextEditor.js?version=12.1p_6_19_2019.

[Isomorphic]

Yes, you can add a URL parameter if you like. However, we would recommend a URL path segment instead, as there are still broken proxies out there that refuse to cache anything that has a URL parameter, even when appropriate headers are set.

[Blama]

Hi user316,

please see this thread, which has more details to your planned way.

Best regards
Blama

[user316]

Yes, you can add a URL parameter if you like. However, we would recommend a URL path segment instead, as there are still broken proxies out there that refuse to cache anything that has a URL parameter, even when appropriate headers are set.

Is it accurate that there is no easy way to add versioning for the .js files this way through the framework, and we would need to create a more complex scheme like Blama linked to, where basically we'd have to dynamically add the versions into the <script> tags with server-side code before the HTML page is passed to the client?

[Isomorphic]

These files are the client framework itself being loaded, the client framework cannot affect its own loading.

There’s no reason this needs to be a dynamic server-side version written out. You can just put a static version into the script tag - someone has to update the version of your app at some point in your process, right? So update the tags then.

Or again, as we recommended: use a URL path segment.

[user316]

Or again, as we recommended: use a URL path segment.

Could you please describe what you mean by a URL path segment? I don't quite understand how that applies here.

[Isomorphic]

We’re just using the term in the standard web way - /path/segment.

If you place the .js files in a subdue by version when you deploy, and reference them that way, you won’t have any cross-version confusion.

[user316]

We’re just using the term in the standard web way - /path/segment.

If you place the .js files in a subdue by version when you deploy, and reference them that way, you won’t have any cross-version confusion.

Alright, that's what I thought you meant. However, this would still require either manually updating the .html each time we deploy a new version, or else create a complex automated scheme where the server (or build tool) would write the versions into the html files before they are sent to the client.

[Isomorphic]

We automated this problem away with JSP tags in our SmartClient product, but unfortunately, GWT makes a pervasive assumpton of a plain .html bootstrap file, such that we can’t recommend trying to incorporate dynamic functionality into this file.

However, build tools like Ant were made for this kind of use case, and if the person who maintains our build system were asked to automate this, he’d call it a trivial task - you will likely get a similar response from whoever maintains your scripts.

In fact there may be a system already in place, as these .js files are just one category of files that could get stale in a new deployment - this whole discussion is just standard HTTP versioning stuff that any kind of deployment must handle, not unique to our product in any way.