title: Rendering complete page and not "progressively" (using struts 2 / tiles)
body: <p>Is there a way to get struts 2 (using tiles) to build the whole page before sending it to the browser? I don't want the page to be build "progressively" in the browser one part at a time.</p>
  
  <p>The main problem I'm trying to solve is that internet explorer 7 flashes/blinks the page even if only some of the content changes (firefox does this much more smoothly).</p>
  
  <p>So that if I have a page with:</p>
  
  <p>HEADER</p>
  
  <p>some content</p>
  
  <p>FOOTER</p>
  
  <p>And the "some content" area only changes between page loads, the FOOTER part still flashes the white background before filling it with the background color of the footer. I tought that maybe by getting struts to send the complete page it would load fast enough to eliminate the "blinking". 
  Now the FOOTER comes from the server a little bit later than the parts before it and so it flashes (in internet explorer, firefox displays the page smoothly).</p>
  
  <p>NB: this is an important requirement for the site, and using ajax to load the middle content is out (as are frames or other "hacks"). The site is built using CSS and not a table layout, maybe I will have to use a table layout to get it to work...</p>
  
  <p>About using tiles flush parameter:
  I tried that and it doesn't work as I need. I would need a flush-parameter for the whole page. I have tried the normal jsp page directive "autoFlush=false" but it didn't work. I set this directive on my main template page (and not in the tiles).</p>
  
  <p>Here is an example from the main template, which uses header, body and footer templates. With the Thread.sleep() I added the problem is easy to spot. The footer renders 2 secs later than the rest of the page.</p>
  
  <pre><code>  &lt;body&gt;
    &lt;div id="container"&gt;
    &lt;t:insertAttribute name="header" flush="false" /&gt;
  
    &lt;div id="content"&gt;&lt;t:insertAttribute name="body" flush="false"/&gt;&lt;/div&gt;
  
    &lt;div class="clear"&gt;&lt;/div&gt;
    &lt;% Thread.sleep(2000); %&gt;
    &lt;t:insertAttribute name="footer" flush="false" /&gt;
    &lt;/div&gt;
    &lt;/body&gt;
  </code></pre>
  
  <p>UPDATE</p>
  
  <p>Thanks for the comments. The requirement is actually almost reasonable as this isn't a normal web page, think embedded.</p>
  
  <p>But apparently there is no way of configuring IE to start rendering after some delay (like firefox has a configurable delay of some 100ms)?</p>
  
  <p>I tried to intercept the TilesResult but the method doExecute is run before the whole content is apparently evaluated, so the method has already exited before the jsp is evaluated (my Thread.sleep() test). I was wondering how I could render the whole response to a string and then output that all at once to the browser.</p>
  
  <p>I know that this isn't foolproof and network delays etc may factor in this, but if I could get the response to output all at once and maybe use a table based layout (IE possibly renders the table only after the table closes) this could work reasonably.</p>
  
  <p>Or then try to get this switched to firefox or maybe forget all about this little glitch...</p>
  
  <p>UPDATE 2</p>
  
  <p>This started to bother me so I did some investigation.
  If I had a plain jsp page (no tiles) the buffering works (with the buffer attribute), so that if I had my Thread.sleep() there the whole page rendered after two seconds if the page size was below the buffer size.
  But if I used tiles in the page (as in the example above) I couldn't get the page to render at the same time (I even included the page directive in all my tiles-templates/"components", no help). So tiles probably flushes the response somewhere?</p>
  
  <p>Furthermore, the "problematic tiles" was my body-part, which contained a struts:form tag. I replaced it with a normal form-tag and it worked as I wanted...</p>
  
  <p>UPDATE 3</p>
  
  <p>Ok, nobody seems to know the inner workings of tiles or struts tags...
  No big problem as this is a very specific case and requirement.
  I worked around it by using apache as a proxt in front of the application, and using apache's proxy configuration options to specify a large buffer.
  I'll mark this as answered.</p>