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#a9996761
Sent from the Wicket - Dev mailing list archive at Nabble.com.
