En este tip mostraré dos ejemplos en los que en uno nos interesa el uso de la memoria en caché y otro en el que nos interesa tenerla deshabilitada.
Caso 1: a favor
Se trata del catálogo un sitio de música, que contiene varios reproductores (prelisteners) hechos en flash. A cada reproductor se le pasa un parámetro con el id del tema a reproducir.
En la línea del param name="movie" se observa que el ID se le pasa al reproductor por URL (metodo GET). Funciona correctamente pero cada reproductor, al ser distinta la URL se baja del servidor nuevamente no aprovechándose el caché. De este modo si ponía por ejemplo 30 reproductores, el peso de la página era enorme, porque se bajaban 30 copias del flash. La solución fué no pasar el parámetro por URL sino por Flasvars, como se vé en la captura de abajo.
De esta manera, cada llamada al flash que está en el servidor es idéntica. Por lo tanto el primer reproductor lo baja del servidor, y los siguientes son instancias del mismo. Siguiendo el ejemplo, a un catálogo con 30 reproductores, solo tendremos que sumarle el peso de 1, aumentando notablemente la performance.
Nota: Para observar la diferencia, además de notarse en la velocidad de carga y reproducción de la página y los objetos Flash, se puede observar la carpeta de archivos temporales de Internet. Si pasamos el ID por URL encontraríamos 30 copias del reproductor:
player.swf
player.swf(1)
....
player.swf(29)
Si lo pasamos con Loadvars, en la misma carpeta solo habría 1: player.swf
En este caso claramente el caché nos favoreció. Por si a alguien le interesa ver el ejemplo "en vivo", les paso la url: dostonos.com
Caso 2: en contra
En este caso se trata de una aplicación hecha en Adbe Flex, con acceso a datos que leemos mediante un XML. Como estos datos varían, no tomamos directamente el .XML; lo generamos con un .php que lee la BD (podría haber sido un .asp o cualquier server-side) de la siguiente manera:
En este caso la memoria caché nos juega en contra. Como la llamada al .php es siempre igual, la primera vez la toma del servidor pero las subsiguientes las toma del caché, haciendo que por más que los datos en nuestra BD hayan cambiado, el .XML resultante sea siempre igual. La solución es cambiar la URL cada vez para obligar al navegador a consultar nuevamente la página del servidor. Para hacerlo agregamos a la URL un parámetro cualquiera que no se usará en el .php, su único objetivo es hacer que la URL sea siempre distinta.
Código :
</mx:Script>
private function traerDatos():void{
var randomNumber:Number=Math.random(); // generamos un numero aleatorio
var oParam:Object = new Object(); // creamos un objeto para pasar al webservice
oParam.id = randomNumber // dentro del objeto creamos el id, que es lo que se pasará como parámetro
this.phpService.send(oParam); // llamamos al webservice
}
</mx:Script>
Tomando este recaudo, cada llamada al .php será distinta por lo que no utilizará el caché. El resultado esperado es que si los datos en el servidor cambiaron, nuestro .XML cambiará y veremos reflejados esos cambios en la aplicación.
Consulta bien la documentación de tu servidor, puesto que puedes activar las etiquetas eTag, no-cache y expires de http 1.1 con los que le puedes indicar al navegador cómo manejará en su caché a esas descargas.
Estas etiquetas las puede aplicar el servidor a cualquier respuesta http que emita, por lo que no importa el contenido que esté enviando.
El único detalle es que habría que asegurarse que en el contexto particular de la aplicación web y los navegadores que típicamente usa el target, no se ignoren estas etiquetas (creo que todos conocemos ya a Murphy). Si no están bien configuradas, en particular flash/flex podría seguir cacheando el contenido. Por:Daniel-blog
flash
php
hack
xml
xhtml
caché
