Perhaps by "page caching" they mean stuff like s:cache
I'm not quite sure what you're saying ... so we should not cache pages in browser but can still use things like s:cache?
How does s:cache change anything...doesn't the page in the cache still need to be re-executed when accessed? And if not (i.e. it's already in HTML), then how's it any better than browser caching?
Is it true that browser caching with Seam is never a good combo?
With s:cache you cache part of pages serverside - i.e. a dynamic part of a page that changes from time to time but is expensive to compute.
With meta tags in html headers you cache whole pages clientside - you can tell the client to ask everytime if theres a newer version available, to use the current page for 24 hours, ... (have a look at the html spec)!
Those 2 have nothing to do with each other. Simply use client side caching if your page hasn't changed and the client has the current version - this saves you cpu time & bandwith and cost just a bit of thinking ;)
I assume you mean browser page caching. I came across this problem with an application that required a login to see customer transaction data. Essentially you could login, view financial data and then log out, after which hitting the back button would show browser cached pages from the previous session. Obviously this caching could potentially reveal sensitive data to a user other than the original customer.
Adding the following meta tags to all my pages (regardless of whether they contained forms, s:link, etc) prevented the browser from caching the pages:
<meta http-equiv="Expires" content="-1" /> <meta http-equiv="Cache-Control" content="no-cache" /> <meta http-equiv="Pragma" content="no-cache" />
This worked well and our application functioned normally after retro fitting the meta tags, however it did cause a problem for our client which may or may not be an issue for you. Our application made heavy use of the commandLink for navigation. This mechanism requires a HTTP post when the link is selected. The side effect of this is that whenever the user selects the browsers' back button, after adding the meta tags the browser has to request a fresh page from the server. Because the original page was generated as the result of a HTTP post, this causes the browser to issue a "Resend Posted information" warning (or something like that) every time the back button is used. This is ugly and is not particularly intuitive and was unacceptable to our client (understandably).
We got around this by replacing all commandLinks that were used purely for navigational purposes with s:link. s:link generates a regular HTML link that allows navigation using HTTP get which solves the browser message problem. One caveat to this solution is that if any navigation requires values from other components on the page or those values are to be saved for later you still have to use commandLink to submit the form data.
Regarding performance: in our case (in fact most cases), security requirements superseded performance requirements, so we had no choice but to turn off browser page caching. That said, you can still get good performance by adopting one or more of the following:
1. As mentioned in previous posts, if a page is particularly expensive to render then caching the expensive page fragments using s:cache is a simple and very effective strategy (e.g. a table bound to a datamodel that requires a complex database query).
2. Introducing appropriate caching policies for external page resources (css, js, images etc) can help to reduce unnecessary server requests and save bandwidth.
3. If your generated pages are large and your users? connections are slow you could add a compression filter to your application. I've used the following compression filter successfully in a Seam application which will cut HTML page sizes by 80% over the wire:
Hope this helps,