why wouldn't you want to cache a panel?  you'd get all the normal
nice wicket components and markup, but it would only render once
in a while to a shared buffer.  i don't think this is really involved in
IResourceStreams.  that seems like a separate issue.  i just think it 
would be extremely convenient to be able to say "i've got this lame
database query i don't have time to optimize or i want to retrieve 
(as you said) some remote resource and i want that cached and 
displayed in a panel that's updated every 3 minutes".  i think that's
a very transparent (no new API except for the method override) and
very powerful way to get something done quickly.  with panel caching,
you can turn a non-performant database query into something that
scales for a large number of users in a few seconds.  without it, you've
got a lot of work to do in the DB layer that requires quite a lot of
specialized knowledge.


Jean-Baptiste Quenot-3 wrote:
> 
> * Jonathan Locke:
> 
> 
>> 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.
> 
> I wish to  implement caching on IResourceStream,  I'm not thinking
> of Page or Component.  Implementing caching on components does not
> make sense to me, unless we can  have a new kind of Component that
> could produce its contents directly from an IResourceStream.
> 
> For  example,  a weather  panel  involving  an HTTP  request,  XML
> parsing and  transformation is expensive  to compute, but  OTOH it
> would be nice  to have this panel embedded in  a Wicket page among
> other "normal" components.   Thus that kind of  component could me
> designed as a ResourceStreamPanel that renders its content by just
> copying the stream's data.
> 
> How such  a component  without real  Markup could  be part  of the
> rendering process?
> -- 
>      Jean-Baptiste Quenot
> aka  John Banana   Qwerty
> http://caraldi.com/jbq/
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Serving-Static-Pages-with-Wicket-tf3572749.html#a9997123
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Reply via email to