you know, it occurs to me that this needs a lot more thought. maybe pages are the wrong granularity for this kind of cached rendering entirely. if we put this method in MarkupContainer instead, panels could participate enabling users to mix and match statefulness and caching. if you have some dynamic but cacheable panel that's incredibly expensive to compute, you can still nest it in a highly stateful page that's just normal wicket.
If it is expensive to compute, it'll be because of the models 99% of the time. Which was why I made my earlier remark (in another thread) caching of render results wouldn't be high on my list of priorities, as that could/ should be done by using smart models and/ or using a second level cache for your database layer. When that is done, rendering should be a piece of cacke. Generating static pages is great for other occasions, such as when you have a heavy traffic news site for instance. I think it is architecturally clumsy to let requests to static pages through Wicket whereas you could just generate them and put them on servers that are optimized for serving static content. Just serve them through Apache, and use whatever load balancing you want. Just my 2c of course. What's interesting about JBQ's proposal as that it opens up some more integration options. That's nice. Eelco
