i think i partly agree with that. but basically you're saying that you should always optimize your response in the business layer. it might be a significant development time savings to avoid having to do most or all of that by simply caching the result in wicket.
Eelco Hillenius wrote: > >> 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 > > -- View this message in context: http://www.nabble.com/Serving-Static-Pages-with-Wicket-tf3572749.html#a9997048 Sent from the Wicket - Dev mailing list archive at Nabble.com.
