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.
Jonathan Locke wrote:
>
>
> these are interesting questions to think about. you could think
> about this as a single shared application scope resource just like
> an image or a pdf file. but that might limit things too much.
> a different scenario might be to still keep instances of the page
> in the user's session, but have those page instances share the same
> interval-rendered buffer. in other words, it would just be a
> normal session-based wicket page that has zero render time
> before responding. it might even be good to support both ways
> of doing this. i think the session based one might be more
> interesting in some ways. i mean you might have a semi-dynamic
> home page (like a news site for example) that gets hit by a lot
> of users and is (for whatever technical reason) not all that quick
> to render. this would really solve that problem well. but the
> gotcha with this whole idea is that people might try to apply
> this thing to problems that are not amenable to it.
>
> we have not had much request for this kind of feature, so i think
> we should take our time doing this for 2.0 or later so we get it right.
>
> jon
>
>
> Johan Compagner wrote:
>>
>> What is the url that hits such a page?
>> Is it session based render? or application scope?
>>
>> for example is it a static bookmarkable page? (so for a session or even
>> an
>> application??)
>> a bookmarkable page request always hits the same instance (or cached
>> static
>> data)
>>
>> johan
>>
>>
>> On 4/14/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>> I want this to be extremely transparent and easy (although more
>>> configuration options could be available elsewhere if they are
>>> truly needed).
>>>
>>> One should be able to do this to any Wicket page and have it
>>> and all its subclasses render on an interval:
>>>
>>> /**
>>> * @return Duration between renders of this page or null to always render
>>> *
>>> */
>>> protected Duration getRenderInterval()
>>> {
>>> return Duration.ONE_MINUTE;
>>> }
>>>
>>> And Page.getRenderInterval() would return null, of course.
>>>
>>> The implementation could simply be to attach an object
>>> to the page using the metadata facility which contains a
>>> last rendered time and a buffer. If the page is asked to
>>> render before the buffer has expired, it simply renders the
>>> buffer as the response.
>>>
>>>
>>> Jean-Baptiste Quenot-3 wrote:
>>> >
>>> > * Jonathan Locke:
>>> >
>>> >
>>> >> Sounds good. And of course there's that earlier thread about
>>> >> making it really easy to make a dynamic page render static
>>> >> snapshots on an interval. That would also be particularly
>>> >> interesting for certain applications.
>>> >
>>> > Indeed caching is the next step, and it is something badly needed
>>> > in Wicket. I remember some weeks ago the developers arguing that
>>> > we don't need ehcache, that makes sense if you only consider
>>> > storing pages, but Wicket's page store is definitely not a
>>> > general-purpose store.
>>> > --
>>> > 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#a9995177
>>> 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#a9996799
Sent from the Wicket - Dev mailing list archive at Nabble.com.
