validacion - validar formulario javascript html5
¿Cómo puedo obligar a los clientes a actualizar los archivos JavaScript? (21)
Actualmente estamos trabajando en una versión beta privada y, por lo tanto, todavía estamos en el proceso de hacer cambios bastante rápidos, aunque, obviamente, a medida que el uso está comenzando a aumentar, estaremos desacelerando este proceso. Dicho esto, uno de los problemas con los que nos encontramos es que después de lanzar una actualización con nuevos archivos JavaScript, los navegadores del cliente todavía usan la versión en caché del archivo y no ven la actualización. Obviamente, en una llamada de soporte, podemos simplemente informarles que realicen una actualización de ctrl F5 para asegurarnos de que obtengan los archivos actualizados del servidor, pero sería preferible manejar esto antes de esa hora.
Nuestra idea actual es simplemente adjuntar un número de versión al nombre de los archivos JavaScript y luego, cuando se realicen los cambios, incrementar la versión en el script y actualizar todas las referencias. Esto definitivamente hace el trabajo, pero actualizar las referencias en cada versión podría volverse incómodo.
Como estoy seguro de que no somos los primeros en lidiar con esto, pensé que lo tiraría a la comunidad. ¿Cómo garantiza que los clientes actualicen su caché cuando actualicen su código? Si está utilizando el método descrito anteriormente, ¿está utilizando un proceso que simplifica el cambio?
¿La solución más sencilla? No deje que el navegador se almacene en absoluto. Agregue la hora actual (en ms) como una consulta.
(Todavía está en la versión beta, por lo que podría hacer un caso razonable para no optimizar el rendimiento. Pero YMMV aquí).
¿Qué hay de agregar el tamaño del archivo como un parámetro de carga?
<script type=''text/javascript'' src=''path/to/file/mylibrary.js?filever=<?=filesize(''path/to/file/mylibrary.js'')?>''></script>
Así que cada vez que actualice el archivo, el parámetro "filever" cambia.
¿Qué tal cuando actualiza el archivo y sus resultados de actualización en el mismo tamaño de archivo? ¿Cuáles son las probabilidades?
A pesar de que es específico del marco, Django 1.4 tiene esta función que funciona de manera similar al enlace al sitio ''greenfelt'' en la respuesta anterior.
Anexar la hora actual a la URL es de hecho una solución común. Sin embargo, también puede gestionar esto en el nivel del servidor web, si lo desea. El servidor se puede configurar para enviar diferentes encabezados HTTP para archivos javascript.
Por ejemplo, para forzar que el archivo se almacene en caché por no más de 1 día, enviaría:
Cache-Control: max-age=86400, must-revalidate
Para la versión beta, si desea forzar al usuario a obtener siempre lo último, usaría:
Cache-Control: no-cache, must-revalidate
El almacenamiento en caché de ASP.NET Core a través de un ayudante de etiquetas manejará esto por usted y permitirá que su navegador guarde los scripts / css en caché hasta que el archivo cambie. Simplemente agregue la etiqueta helper asp-append-version = "true" a su etiqueta de script (js) o enlace (css):
<link rel="stylesheet" href="~/css/site.min.css" asp-append-version="true"/>
Dave Paquette tiene un buen ejemplo y una explicación del almacenamiento en caché aquí (parte inferior de la página)
En PHP :
function latest_version($file_name){
echo $file_name."?".filemtime($_SERVER[''DOCUMENT_ROOT''] .$file_name);
}
En HTML :
<script type="text/javascript" src="<?php latest_version(''/a-o/javascript/almanacka.js''); ?>">< /script>
Cómo funciona:
En HTML, escriba la filepath y el nombre como lo haría, pero solo en la función. PHP obtiene el filetime de archivo del archivo y devuelve la filetime de filepath+name+"?"+time del último cambio
Esta respuesta llega solo 6 años tarde, pero no veo esta respuesta en muchos lugares ... HTML5 ha introducido Application Cache que se usa para resolver este problema. Descubrí que el nuevo código de servidor que estaba escribiendo estaba bloqueando el antiguo javascript almacenado en los navegadores de las personas, por lo que quería encontrar una forma de caducar su javascript. Utilice un archivo de manifiesto que se parece a esto:
CACHE MANIFEST
# Aug 14, 2014
/mycode.js
NETWORK:
*
y genere este archivo con una nueva marca de tiempo cada vez que desee que los usuarios actualicen su caché. Como nota al margen, si agrega esto, el navegador no se volverá a cargar (incluso cuando un usuario actualice la página) hasta que el manifiesto lo indique.
Google Page-Speed: no incluya una cadena de consulta en la URL para recursos estáticos. La mayoría de los proxies, especialmente Squid hasta la versión 3.0, no almacenan en caché los recursos con un "?" en su URL, incluso si hay un encabezado Cache-control: public en la respuesta. Para habilitar el almacenamiento en caché del proxy para estos recursos, elimine las cadenas de consulta de las referencias a los recursos estáticos y, en su lugar, codifique los parámetros en los nombres de los archivos.
En este caso, puede incluir la versión en la URL ej: http://abc.com/ v1.2 /script.js y usar apache mod_rewrite para redirigir el enlace a http://abc.com/script.js . Cuando cambie la versión, el navegador del cliente actualizará el nuevo archivo.
Hemos estado creando un SaaS para usuarios y les hemos proporcionado un script para adjuntar en la página de su sitio web, y no fue posible adjuntar una versión con el script, ya que el usuario adjuntará el script a su sitio web para las funcionalidades y no puedo forzarlo. Para cambiar la versión cada vez que actualizamos el script.
Por lo tanto, encontramos una forma de cargar la versión más nueva del script cada vez que el usuario llama al script original
el enlace del script proporcionado al usuario
<script src="https://thesaasdomain.com/somejsfile.js" data-ut="user_token"></script>
el archivo de script
if($(''script[src^="https://thesaasdomain.com/somejsfile.js?"]'').length !== 0) {
init();
} else {
loadScript("https://thesaasdomain.com/somejsfile.js?" + guid());
}
var loadscript = function(scriptURL) {
var head = document.getElementsByTagName(''head'')[0];
var script = document.createElement(''script'');
script.type = ''text/javascript'';
script.src = scriptURL;
head.appendChild(script);
}
var guid = function() {
return ''xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx''.replace(/[xy]/g, function(c) {
var r = Math.random() * 16 | 0, v = c == ''x'' ? r : (r & 0x3 | 0x8);
return v.toString(16);
});
}
var init = function() {
// our main code
}
Explicación:
El usuario ha adjuntado el script que se les proporcionó en su sitio web y verificamos si el token único adjunto con el script existe o no utiliza el selector jQuery y, si no, lo cargamos dinámicamente con el token (o versión) más reciente.
Esto se llama al mismo script dos veces, lo que podría ser un problema de rendimiento, pero realmente resuelve el problema de forzar que el script no se cargue desde la memoria caché sin colocar la versión en el enlace del script real dado al usuario o cliente
Descargo de responsabilidad: no utilice si el rendimiento es un gran problema en su caso.
La función jQuery getScript también se puede utilizar para garantizar que un archivo js se carga cada vez que se carga la página.
Así es como lo hice:
$(document).ready(function(){
$.getScript("../data/playlist.js", function(data, textStatus, jqxhr){
startProgram();
});
});
Compruebe la función en http://api.jquery.com/jQuery.getScript/
De forma predeterminada, $ .getScript () establece la configuración de caché en falso. Esto agrega un parámetro de consulta con marca de tiempo a la URL de solicitud para garantizar que el navegador descarga la secuencia de comandos cada vez que se solicita.
La práctica común hoy en día es generar un código hash de contenido como parte del nombre del archivo para forzar al navegador, especialmente a IE, a volver a cargar los archivos javascript o css.
Por ejemplo,
vendedor. a7561fb0e9a071baadb9 .js
principal. b746e3eb72875af2caa9 .js
Generalmente es el trabajo para las herramientas de compilación, como el paquete web. Aquí hay más details si alguien quiere probar si está utilizando un paquete web.
La ventaja de usar un file.js?V=1 sobre un fileV1.js es que no necesita almacenar varias versiones de los archivos JavaScript en el servidor.
El problema que veo con file.js?V=1 es que puede tener un código dependiente en otro archivo JavaScript que se rompe al usar la nueva versión de las utilidades de la biblioteca.
En aras de la compatibilidad con versiones anteriores, creo que es mucho mejor usar jQuery.1.3.js para sus nuevas páginas y dejar que las páginas existentes usen jQuery.1.1.js , hasta que esté listo para actualizar las páginas anteriores, si es necesario.
Mi colega acaba de encontrar una referencia a ese método justo después de que publiqué (en referencia a css) en http://www.stefanhayden.com/blog/2006/04/03/css-caching-hack/ . Es bueno ver que otros lo están usando y parece funcionar. Supongo que en este punto no hay una mejor manera que buscar y reemplazar para incrementar estos "números de versión" en todas las etiquetas de script.
No todos los navegadores almacenan archivos en caché con ''?'' en eso. Lo que hice para asegurarme de que estuviera guardado lo más posible, incluí la versión en el nombre del archivo.
Así que en lugar de stuff.js?123 , hice stuff_123.js
mod_redirect (creo) en apache para have stuff_*.js stuff.js para ir stuff.js
Para ASP.NET supongo que la próxima solución con opciones avanzadas (modo debug / release, versiones):
Js o archivos css incluidos por tal forma:
<script type="text/javascript" src="Scripts/exampleScript<%=Global.JsPostfix%>" />
<link rel="stylesheet" type="text/css" href="Css/exampleCss<%=Global.CssPostfix%>" />
Global.JsPostfix y Global.CssPostfix se calculan de la siguiente manera en Global.asax:
protected void Application_Start(object sender, EventArgs e)
{
...
string jsVersion = ConfigurationManager.AppSettings["JsVersion"];
bool updateEveryAppStart = Convert.ToBoolean(ConfigurationManager.AppSettings["UpdateJsEveryAppStart"]);
int buildNumber = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Revision;
JsPostfix = "";
#if !DEBUG
JsPostfix += ".min";
#endif
JsPostfix += ".js?" + jsVersion + "_" + buildNumber;
if (updateEveryAppStart)
{
Random rand = new Random();
JsPosfix += "_" + rand.Next();
}
...
}
Para las páginas ASP.NET estoy usando lo siguiente
ANTES DE
<script src="/Scripts/pages/common.js" type="text/javascript"></script>
DESPUÉS (forzar recarga)
<script src="/Scripts/pages/common.js?ver<%=DateTime.Now.Ticks.ToString()%>" type="text/javascript"></script>
Agregar el DateTime.Now.Ticks funciona muy bien.
Si está generando la página que enlaza con los archivos JS, una solución simple es agregar la marca de tiempo de la última modificación del archivo a los enlaces generados.
Esto es muy similar a la respuesta de Huppie, pero funciona en sistemas de control de versiones sin sustitución de palabras clave. También es mejor que agregar la hora actual, ya que eso evitaría el almacenamiento en caché incluso cuando el archivo no cambiara nada.
Una forma sencilla. Editar htaccess
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} /.(jpe?g|bmp|png|gif|css|js|mp3|ogg)$ [NC]
RewriteCond %{QUERY_STRING} !^(.+?&v33|)v=33[^&]*(?:&(.*)|)$ [NC]
RewriteRule ^ %{REQUEST_URI}?v=33 [R=301,L]
Una solución es agregar una cadena de consulta con una marca de tiempo en la URL al obtener el recurso. Esto aprovecha el hecho de que un navegador no almacenará en caché los recursos obtenidos de las URL con cadenas de consulta en ellos.
Sin embargo, es probable que no desee que el navegador no almacene en caché estos recursos; es más probable que desee que estén en caché, pero desea que el navegador obtenga una nueva versión del archivo cuando esté disponible.
La solución más común parece ser incrustar una marca de tiempo o un número de revisión en el nombre del archivo. Esto es un poco más de trabajo, ya que su código debe modificarse para solicitar los archivos correctos, pero significa que, por ejemplo, la versión 7 de su snazzy_javascript_file.js (es decir, snazzy_javascript_file_7.js ) se snazzy_javascript_file_7.js en caché en el navegador hasta que libere la versión 8. y luego su código cambia para buscar snazzy_javascript_file_8.js en snazzy_javascript_file_8.js lugar.
Use una variable GET versión para evitar el almacenamiento en caché del navegador.
Anexar ?v=AUTO_INCREMENT_VERSION al final de su URL evita el almacenamiento en caché del navegador, evitando todos y cada uno de los scripts almacenados en caché.
Por lo que sé, una solución común es agregar una ?<version> al enlace src del script.
Por ejemplo:
<script type="text/javascript" src="myfile.js?1500"></script>
Supongo que en este punto no hay una mejor manera que buscar y reemplazar para incrementar estos "números de versión" en todas las etiquetas de script.
¿Podría tener un sistema de control de versiones que haga eso por usted? La mayoría de los sistemas de control de versiones tienen una forma de inyectar automáticamente el número de revisión en el registro, por ejemplo.
Se vería algo como esto:
<script type="text/javascript" src="myfile.js?$$REVISION$$"></script>
Por supuesto, siempre hay mejores soluciones como esta .