You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jean-Baptiste Quenot <jb...@apache.org> on 2007/04/13 18:53:59 UTC
Serving Static Pages with Wicket
I'm going to add some examples for static pages in Wicket. That
is serving files (or more generally data streams) by reusing the
powerful Wicket concepts like IResourceStream, IRequestTarget and
of course RequestCycle. By static pages I mean stateless pages
not using Components, in fact those pages can be also considered
dynamic if you take the example of an XSLT transform.
It consists of simple base classes and a small example to be able
to integrate static pages in a Wicket application. For example in
my current project, this mechanism is used to display the
documentation pages, alongside the "normal" Wicket powerful and
stateful Ajax UI.
This is the list of things I wish to add in core (not to mention
examples):
* XSLTResourceStream: IResourceStream that applies XSLT on an
IResourceStream (WICKET-465)
* URIRequestTargetUrlCodingStrategy: Request coding strategy that
uses a simple URI (WICKET-469). I'm also using that for my
soon-to-be-released Wicket photo gallery, the idea is that the
remaining part of the URI after the mount denotes a file path.
* WebExternalResourceStream: An IResourceStream that reads data
from a file in the web application
* PackageResourceStream: An IResourceStream that reads data from a
resource in the classpath
And of course the existing FileResourceStream,
ResourceStreamRequestTarget and co are very helpful for serving
static pages.
Currently in Wicket it's not obvious how to serve static pages,
and users have requested this feature, see
http://www.nabble.com/Joost-uses-Wicket-tf3390296.html#a9527502
http://www.nabble.com/Static-pages--tf3026287.html#a8407550
Pointing them to simple examples would help them implement such a
feature in an eye blink.
WDYT?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Serving Static Pages with Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
Sounds interesting, especially as you want to provide a bunch of examples. So +1
Eelco
On 4/13/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> I'm going to add some examples for static pages in Wicket. That
> is serving files (or more generally data streams) by reusing the
> powerful Wicket concepts like IResourceStream, IRequestTarget and
> of course RequestCycle. By static pages I mean stateless pages
> not using Components, in fact those pages can be also considered
> dynamic if you take the example of an XSLT transform.
>
> It consists of simple base classes and a small example to be able
> to integrate static pages in a Wicket application. For example in
> my current project, this mechanism is used to display the
> documentation pages, alongside the "normal" Wicket powerful and
> stateful Ajax UI.
>
> This is the list of things I wish to add in core (not to mention
> examples):
>
> * XSLTResourceStream: IResourceStream that applies XSLT on an
> IResourceStream (WICKET-465)
>
> * URIRequestTargetUrlCodingStrategy: Request coding strategy that
> uses a simple URI (WICKET-469). I'm also using that for my
> soon-to-be-released Wicket photo gallery, the idea is that the
> remaining part of the URI after the mount denotes a file path.
>
> * WebExternalResourceStream: An IResourceStream that reads data
> from a file in the web application
>
> * PackageResourceStream: An IResourceStream that reads data from a
> resource in the classpath
>
> And of course the existing FileResourceStream,
> ResourceStreamRequestTarget and co are very helpful for serving
> static pages.
>
> Currently in Wicket it's not obvious how to serve static pages,
> and users have requested this feature, see
> http://www.nabble.com/Joost-uses-Wicket-tf3390296.html#a9527502
> http://www.nabble.com/Static-pages--tf3026287.html#a8407550
>
> Pointing them to simple examples would help them implement such a
> feature in an eye blink.
>
> WDYT?
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Serving Static Pages with Wicket
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Eelco Hillenius:
> 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
That's a very good point indeed. When a Component's Model need to
be cached, that needs to be taken care of in the custom Model
directly.
But for static (or dynamic) pages not involving Components,
we should still decide whether we want an object store or
not, because in this case there is no Model, just the basic
IResourceStream, IRequestTarget, and so on.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com> 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.
Re: Serving Static Pages with Wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jo...@gmail.com> 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.
>
>
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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.
Re: Serving Static Pages with Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
yeah, maybe this is a wicket-stuff project for now (if at all).
Eelco Hillenius wrote:
>
> On 4/14/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>> 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.
>
> But again, it's really the models behind the components you should be
> tweaking. I'm afraid that making caching output a core capability of
> components will distract users to much of what they're really should
> be looking at (models). Also, if you really want, you can make such
> caching components yourself today, which let's me doubt even more we
> need to provide this as standard functionality.
>
> Eelco
>
>
--
View this message in context: http://www.nabble.com/Serving-Static-Pages-with-Wicket-tf3572749.html#a9997442
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Serving Static Pages with Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
On 4/14/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> 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.
But again, it's really the models behind the components you should be
tweaking. I'm afraid that making caching output a core capability of
components will distract users to much of what they're really should
be looking at (models). Also, if you really want, you can make such
caching components yourself today, which let's me doubt even more we
need to provide this as standard functionality.
Eelco
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
ah. i see i changed the subject not you. my bad.
Jean-Baptiste Quenot-3 wrote:
>
> * Jonathan Locke:
>
>
>> btw, i think caching on IResourceStream is a good idea. a
>> separate topic, i think, but a good idea.
>
> If I quote you the other way around I would say:
>
> Caching the markup generated by components is a good idea. A
> separate topic, I think, but a good idea.
>
> This very thread is not about caching the markup of Components in
> the first place. It's about using IResourceStream and request
> targets to serve non-component-based pages.
> --
> 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#a9997441
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Serving Static Pages with Wicket
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Jonathan Locke:
> btw, i think caching on IResourceStream is a good idea. a
> separate topic, i think, but a good idea.
If I quote you the other way around I would say:
Caching the markup generated by components is a good idea. A
separate topic, I think, but a good idea.
This very thread is not about caching the markup of Components in
the first place. It's about using IResourceStream and request
targets to serve non-component-based pages.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
btw, i think caching on IResourceStream is a good idea. a separate
topic, i think, but a good idea.
Jonathan Locke wrote:
>
>
> 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#a9997127
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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.
Re: Serving Static Pages with Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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?
An easy solution would be to do it like a Label does, replacing the body.
Eelco
Re: Serving Static Pages with Wicket
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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/
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com> 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.
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com> 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.
Re: Serving Static Pages with Wicket
Posted by Johan Compagner <jc...@gmail.com>.
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 <jo...@gmail.com> 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.
>
>
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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.
Re: Serving Static Pages with Wicket
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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/
Re: Serving Static Pages with Wicket
Posted by Jonathan Locke <jo...@gmail.com>.
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.
Jean-Baptiste Quenot-3 wrote:
>
> I'm going to add some examples for static pages in Wicket. That
> is serving files (or more generally data streams) by reusing the
> powerful Wicket concepts like IResourceStream, IRequestTarget and
> of course RequestCycle. By static pages I mean stateless pages
> not using Components, in fact those pages can be also considered
> dynamic if you take the example of an XSLT transform.
>
> It consists of simple base classes and a small example to be able
> to integrate static pages in a Wicket application. For example in
> my current project, this mechanism is used to display the
> documentation pages, alongside the "normal" Wicket powerful and
> stateful Ajax UI.
>
> This is the list of things I wish to add in core (not to mention
> examples):
>
> * XSLTResourceStream: IResourceStream that applies XSLT on an
> IResourceStream (WICKET-465)
>
> * URIRequestTargetUrlCodingStrategy: Request coding strategy that
> uses a simple URI (WICKET-469). I'm also using that for my
> soon-to-be-released Wicket photo gallery, the idea is that the
> remaining part of the URI after the mount denotes a file path.
>
> * WebExternalResourceStream: An IResourceStream that reads data
> from a file in the web application
>
> * PackageResourceStream: An IResourceStream that reads data from a
> resource in the classpath
>
> And of course the existing FileResourceStream,
> ResourceStreamRequestTarget and co are very helpful for serving
> static pages.
>
> Currently in Wicket it's not obvious how to serve static pages,
> and users have requested this feature, see
> http://www.nabble.com/Joost-uses-Wicket-tf3390296.html#a9527502
> http://www.nabble.com/Static-pages--tf3026287.html#a8407550
>
> Pointing them to simple examples would help them implement such a
> feature in an eye blink.
>
> WDYT?
> --
> 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#a9994806
Sent from the Wicket - Dev mailing list archive at Nabble.com.