Influencing Browser Caching with Sencha Cmd for an ExtJS 4 App

[grekker]

Is it possible with Sencha Cmd to add a parameter to a script src property to encourage browsers to dump their cached version of the file?

Right now Sencha Cmd turns this:

<!-- <x-compile> -->
  <!-- <x-bootstrap> -->    
    <script src="/ext-4.1.1a/ext-debug.js" type="text/javascript"></script>  
  <!-- </x-bootstrap> -->
  <script src="/app.js" type="text/javascript"></script>
<!-- </x-compile> -->

Into this:

<script type="text/javascript" src="all-classes.js"></script>

We're running into a minor but annoying problem. Browsers are caching the all-classes.js file and when we push changes (which we do quite frequently, every other day or so) not all users get them until some time later.

Is it possible to use Sencha Cmd to instead generate something like this:

<script type="text/javascript" src="all-classes.js?version=43208374"></script>

Where version is just some random number or timestamp that is added so that each time you run Sencha Cmd browsers will see the new parameter and replace their cached versions?

Thanks!

P.S. My backup plan is to just do this myself using SED or equivalent as part of our deploy process, but figured I wouldn't re-invent the wheel if Cmd could already do it for me. Looked in the docs, didn't see anything about this.

[dongryphon]

The name "all-classes.js" is a build property. From .sencha/app/build-impl.xml (line 116 of the "init" target):

    <property name="build.classes.name" value="all-classes.js"/>

While changing build-impl.xml is not recommended, you can provide your own value in build.xml like so:

    <target name="-before-init">
        <tstamp>
            <format property="tstamp.full" pattern="yyyy-MM-dd-HH-mm-ss"/>
        </tstamp>

        <property name="build.classes.name"
                  value="all-classes.js?version=${tstamp.full}"/>
    </target>

[grekker]

Thanks for the reply. Glad to hear there's a way to do it.

My application was not generated by Sencha Cmd. I'm just using the following command to compile it:

sencha -s=public/ext-4.1.1a compile -classpath=public/ext-4.1.1a/examples/ux,public/app,public/app.js page -yui -in public/development.php -out public/index.php

Is there a way to incorporate build.xml into this process, or do I need to mess around with generating a new application and migrate mine?

[dongryphon]

At that level, the page command has a switch to specify the generated filename. Though now that I think about it, we may need to allow the file name and the src attribute to have different values.

But you could just give the actual file name the date/time stamp instead of using ?version= and get the desired affect.

If you want to experiment with the generated build scripts, the easiest way is to copy the build.xml and .sencha folder from one a dummy app over to your app. There may be changed needed to some config values, but that is probably easier than moving your app around. Depends how similar or dissimilar things are between what you have and what the generated scripts assume.

[grekker]

Quick PSA to help anyone that found this thread searching for how to version deployed builds.

Now that 4.2 is well and truly out in the wild, we've bitten the bullet and started migrating our app from the old folder structure to the new, shiny Sencha Cmd structure that comes with 4.2.

For the last few months I followed dongryphon's original advice about using a switch in the page command to manually specify a version number each time I built.

Now that we're using 4.2 (and Sencha Cmd 3.1.1.274) I tried to use dongryphon's original suggestion (modify the build.xml file) and realized that the original suggestion doesn't work.

If you put

<property name="build.classes.name" value="all-classes.js?version=${tstamp.full}"/>

it will generate an actual file that includes the entire timestamp, including the question mark.

However, browsers assume that question marks indicate parameters for a file, so the browser still looks for an "all-classes.js" file. Consequently, no file is found.

You can get around this by simply using:

<property name="build.classes.name" value="all-classes-${tstamp.full}.js"/>

which as you can see embeds the timestamp in the filename in a way browsers will understand.

However, none of this really solves the original objective in its true spirit: versioning a deployed file so that browsers clear their cache. We've achieved the same result but by basically cloning the deployed file over and over. This clutters up your build folder and messes with any version control you've got going on.

Now dongryphon already alluded to the way to really fix this problem: split the generated file name and the src attribute into two different variables. If the Sencha team does this in a later Sencha Cmd version we could quite easily version the deployed script in a clean, friendly way.

Here's hoping!