Forzatura degli aggiornamenti dell'applicazione ExtJS dopo la distribuzione

Volete eseguire la versione del file ext durante la distribuzione. Quindi, invece di avere:

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

Puoi avere:

<script type="text/javascript" src="ext-all-4-0-2a.js"></script>

Avrebbe un'intestazione della cache che non scade mai e quando si aggiorna ad un'altra versione il nome sarà cambiato e costringerà il browser a caricare il nuovo file.

Quando esegui l'upgrade a Ext 4.2, ad esempio, sarebbe:

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

Ecco una buona annotazione sul web development di livello di distribuzione. link Assicurati di controllare la sezione "Aggiungi una scadenza o un'intestazione di controllo della cache" che parla della versione. Il controllo delle versioni dovrebbe anche essere eseguito con gli script a livello di componente / applicazione.

Questa è una spina spudorata, ma puoi controllare la fonte del mio sito web link che è un'applicazione django scritta in Ext per vedere la versione in azione.

Sembra che tu stia incontrando problemi con il browser che memorizza nella cache versioni precedenti dei tuoi file di applicazioni e risorse. Questo è un problema comune dato che i browser web sono cache "avide" e avranno notevoli difficoltà a non utilizzare versioni aggiornate.

Hai alcune opzioni. ExtJS stesso supporta un'opzione "no-cache" che può essere configurata tramite una configurazione di caricamento dell'applicazione. disabilita la configurazione della cache . Ciò farà sì che il tuo browser recuperi ogni file nuovamente su ogni carico. Questo può avere alcuni effetti negativi se l'applicazione cambia raramente (ogni 3 mesi circa), ma stai costringendo gli utenti a scaricare MB di file applicativi per ogni carico. Ciò tuttavia è molto buono quando si è in fase di sviluppo e si modificano regolarmente il codice.

Per l'app che cambia raramente, utilizzo un nome di applicazione personalizzato ("aka, b3.0-myapp") e includo tutti i file di app nella directory b3.0-myapp. Quando si verifica il tempo di aggiornamento, rinominare l'app b3.1-myapp e spostare la directory dell'app. È quindi possibile eseguire alcuni load manager di errori (ovvero il loro codice tenta ancora di caricare 3.0) e presentare un messaggio con garbo a quel punto.

Il controllo delle versioni delle risorse statiche è una delle opzioni. Personalmente utilizzo un sistema build poiché ho troppi file da aggiornare manualmente. Ecco un esempio barebone che utilizza gulp , ma devi essere in grado di fare lo stesso nel tuo sistema di build / task run preferito:

// gulpfile.js
var gulp = require( "gulp" ),
    ... other modules
    htmlReplace = require( "gulp-html-replace" ),
    replace = require( "gulp-replace" );

gulp.task( "html-resources", function () {

    return gulp.src( "./" + config.dir.build + "/**/*" )

        // using gulp-html-replace module
        .pipe( htmlReplace({

            // single instance
            "configFile": "config.js?ver=@version@",

            // multiple-instances
            "bowerComponents": {
                "src": config.files.source.bowerComponents, // ["lib1.js",...]
                "tpl": "<script src=\"assets/%s?ver=@version@\"></script>"
        },
        }))

        // using gulp-replace module
        .pipe( replace( "@version@", version ) )
        .pipe( gulp.dest("./" + config.dir.build) );
});

Anche una strategia utile per il controllo delle versioni consiste nell'utilizzare ad esempio checksum CRC del file come versione. In questo modo il tuo cliente non avrà bisogno di scaricare un sacco di nuovi file, solo perché hai aggiornato un file ma hai dovuto aumentare la versione per tutti.

Imposta la proprietà di aggiornamento per app.js su full in app.json:

{
    // Path to file. If the file is local this must be a relative path from this app.json file.
    "path": "app.js",

    "bundle": true,  /* Indicates that all class dependencies are concatenated into this file when build */

    // If 'update' not specified, this file will only be loaded once, and cached inside
    // localStorage until this value is changed. You can specify:
    //   - "delta" to enable over-the-air delta update for this file
    //   - "full" means full update will be made when this file changes
    "update": "full"
}

Disabilita la cache in extjs in modo che il browser ottenga i dati dal server. Per fare ciò, aggiungi il seguente file app.json.     "produzione": {         "cache": {             "Abilita": falso         }     }

Questo è un problema sociale e non proprio un problema tecnologico. Devi informare l'utente che la tua applicazione è stata aggiornata.

Un buon esempio è Google Chrome. Si aggiorna in background e aspetta. Se non riavvii Google Chrome tra circa una settimana, questo ti darà un messaggio umoristico che dice qualcosa sul fatto che "è passato molto tempo da quando hai riavviato il browser. Riavvia il browser per ottenere la versione aggiornata.

Potresti fare qualcosa di simile. Avere un servizio che risponde con il numero di versione della tua applicazione. Invia una richiesta Ajax a questo servizio ogni giorno o qualcosa del genere. e se il numero di versione è aumentato, mostra un messaggio all'utente ..