Changing my search query to this got some better hits: http://lmgtfy.com/?q=cacheability So, allow me to refine my question based on that - has anyone tried some of these approaches (see first result from above) to generrate and dump content to a static file (renamed if it chages) and having the wicket home page be a redirect to that file, or something like that?
Thanks, -- Jim. On Thu, Mar 26, 2009 at 12:53 PM, Jim Pinkham <pinkh...@gmail.com> wrote: > I've found a few posts about how to mark dynamic pages so they won't be > cached. > > I've got a different situation that I think is fairly common - the 'home' > page of my app is effectively a (cheesr-like) catalog of items that changes > infrequently. Users didn't like paging, so it's about 300 items in a > simple scrollable page. Once a user views it, they often drill down into an > item, then use the back button (or sometimes the Home link) to re-display > it. > > The db query is actually pretty fast; I think the bottleneck seems to be > fetching the HTML. > > My question is, can I use some kind of header caching hint with a version > number so that once the content is identified as being the same as a > previously fetched page, the user's browser will repaint it from a local > cache? (I know this is typically done with images, but I was wondering if > this would make sense to do also do with content that technically 'dynamic' > but actually is 'fairly static' ? (I say version number rather than time > to expire so that in case I add/change an item I can increment the catalog > version) > > Thanks, > -- Jim >
