Renderizando la página completa y no & # 8220; progresivamente & # 8221; (usando puntales 2 / azulejos)
https://stackoverflow.com/questions/438954
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Hay alguna manera de obtener puntales 2 (usando mosaicos) para construir toda la página antes de enviarla al navegador? No quiero que la página se construya "progresivamente" en el navegador una parte a la vez.
El principal problema que estoy tratando de resolver es que Internet Explorer 7 muestra / parpadea la página incluso si solo cambia parte del contenido (Firefox lo hace mucho más suavemente).
De modo que si tengo una página con:
CABECERO
algún contenido
PIE DE PIE
Y el " algún contenido " el área solo cambia entre las cargas de página, la parte FOOTER aún muestra el fondo blanco antes de rellenarlo con el color de fondo del pie de página. Pensé que quizás al obtener struts para enviar la página completa se cargaría lo suficientemente rápido como para eliminar el "parpadeo". Ahora, FOOTER viene del servidor un poco más tarde que las partes anteriores y, por lo tanto, parpadea (en Internet Explorer, Firefox muestra la página sin problemas).
NB: este es un requisito importante para el sitio, y el uso de ajax para cargar el contenido intermedio está fuera (al igual que los marcos u otros "hacks"). El sitio está construido usando CSS y no un diseño de tabla, tal vez tendré que usar un diseño de tabla para que funcione ...
Acerca del uso del parámetro de descarga de mosaicos: Lo intenté y no funciona como lo necesito. Necesitaría un parámetro de descarga para toda la página. He intentado la directiva de página jsp normal " autoFlush = false " Pero no funcionó. Establecí esta directiva en mi página de plantilla principal (y no en los mosaicos).
Aquí hay un ejemplo de la plantilla principal, que usa plantillas de encabezado, cuerpo y pie de página. Con Thread.sleep () agregué que el problema es fácil de detectar. El pie de página se procesa 2 segundos más tarde que el resto de la página.
<body>
<div id="container">
<t:insertAttribute name="header" flush="false" />
<div id="content"><t:insertAttribute name="body" flush="false"/></div>
<div class="clear"></div>
<% Thread.sleep(2000); %>
<t:insertAttribute name="footer" flush="false" />
</div>
</body>
ACTUALIZACIÓN
Gracias por los comentarios. El requisito es en realidad casi razonable, ya que esta no es una página web normal, piensa incrustada.
¿Pero aparentemente no hay forma de configurar IE para comenzar a renderizar después de un retraso (como Firefox tiene un retraso configurable de unos 100 ms)?
Traté de interceptar el TilesResult pero el método doExecute se ejecuta antes de que aparentemente se evalúe todo el contenido, por lo que el método ya salió antes de que se evalúe el jsp (mi prueba Thread.sleep ()). Me preguntaba cómo podría representar toda la respuesta a una cadena y luego enviarla de una vez al navegador.
Sé que esto no es infalible y los retrasos de la red, etc. pueden tener esto en cuenta, pero si pudiera obtener la respuesta a la salida de una vez y tal vez usar un diseño basado en una tabla (IE posiblemente representa la tabla solo después de que la tabla se cierre ) esto podría funcionar razonablemente.
O intenta cambiar esto a Firefox o tal vez te olvides de este pequeño error ...
ACTUALIZACIÓN 2
Esto comenzó a molestarme, así que investigué un poco. Si tuviera una página jsp simple (sin mosaicos), el almacenamiento en búfer funciona (con el atributo buffer), de modo que si tuviera mi Thread.sleep (), la página completa se representaría después de dos segundos si el tamaño de la página estaba por debajo del tamaño del búfer. Pero si utilicé mosaicos en la página (como en el ejemplo anterior) no pude hacer que la página se procesara al mismo tiempo (incluso incluí la directiva de página en todas mis plantillas de mosaicos / `` componentes '', no ayuda) . Entonces, ¿los mosaicos probablemente eliminen la respuesta en alguna parte?
Además, los "mosaicos problemáticos" era mi parte del cuerpo, que contenía una etiqueta struts: form. Lo reemplacé con una etiqueta de formulario normal y funcionó como quería ...
ACTUALIZACIÓN 3
Ok, nadie parece saber el funcionamiento interno de las etiquetas de azulejos o puntales ... No es un gran problema ya que este es un caso y requisito muy específico. Trabajé alrededor usando apache como proxt delante de la aplicación y usando las opciones de configuración de proxy de apache para especificar un búfer grande. Marcaré esto como contestado.
Solución
¿Puedes usar el " flush " atributo en los componentes de mosaicos?
<tiles:insertAttribute name="body" flush="false"/>
Además, si el búfer de salida es demasiado grande, se vaciará de todos modos. ¿Intenta aumentar el tamaño del búfer?
<%@ page language="java" buffer="500kb" autoFlush="false" %>
Otros consejos
Si lo desea, puede enviar todos los datos de la página al mismo tiempo al final del servidor (y muchos marcos lo hacen de todos modos por conveniencia), pero la realidad de las redes es que no todo llegará de una vez y el navegador lo mostrará como Llegan los paquetes. Y esto es bueno para la capacidad de respuesta, incluso si * estéticamente desea que la página se muestre de una vez.
Puede reducir el retraso tanto como sea posible simplificando el marcado y usando la compresión desinflada para mantener el tamaño de la carga útil bajo, y eso es algo que vale la pena hacer en general. Además, puede asegurarse de que no está alcanzando un Flash de contenido sin estilo. Pero no puede controlar cuándo el navegador elige renderizar, a menos que lo haga todo en JavaScript con todas las desventajas que esto conlleva (e incluso entonces, el navegador puede volver a dibujar lentamente).
(* - o su cliente / jefe, si ese es el que ha presentado este '' requisito importante '' de que su sitio de alguna manera funcione de manera diferente a cualquier otra página en la web.)
