i dont think that is what eelco is saying. imodel is not part of the
business layer, it is part of the ui layer. so you can cache there. the
render process of the panel itself is very quick, i do not see why you would
want to cache _that_.
for example take jbq's example of a weather panel. lets say there is some
webservice that sends back some xml forecast. what you want is to apply some
xsl to that xml to make it easier to parse, and then create a datastructure
that you use to render the panel.
what you can do is perform caching in the imodel so it looks like this:
class weatherforecastmodel extends abstractreadonlymodel {
private transient Forecast cache;
private transient Date last;
public object getobject() {
if (last==null||last.olderthenfiveminutes()) {
string xml=wget(serviceurl);
xml=xslt(xml);
cache=new Forecast(xml);
last=new date();
}
return cache;
}
}
the difference between what you propose and the above is only the render
time of the listview that will render the forecast stored in Forecast
object. render time of listview is minimal compared to the price of storing
html somewhere (prob in session).
the above model probably cached around 99% of total rendering time for that
panel, and i think that is good enough.
-igor
On 4/14/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
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.
