well, you do have to make your model implementation do this
caching. but yeah, that makes more sense now. still, the tradeoff
is not bad for panel caching at application scope, which is what
i'm talking about (where the panel is truly static for all users).
i agree (of course) it would not be worth caching html in the session
to save rendering it. that's silly.
igor.vaynberg wrote:
>
> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Serving-Static-Pages-with-Wicket-tf3572749.html#a9997440
Sent from the Wicket - Dev mailing list archive at Nabble.com.
