You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Alberto Brosich <ab...@inogs.it> on 2019/02/28 09:36:49 UTC
Best practice for custom page renderer
Hello,
I didn't find any useful information about that in the documentation.
For some reasons (e.g. search engine bots or clients unable to follow
redirects) on some pages I would like to have an http 200 response. By
default Wicket uses REDIRECT_TO_BUFFER render strategy that send a 302
redirect first.
Which is the best practice for use ONE_PASS_RENDER strategy?
Is it reasonable to adopt ONE_PASS_RENDER for all stateless pages or is
it better to change the render strategy only for specific pages?
Is setPageRendererProvider() the good place where to handle that?
For example:
setPageRendererProvider( new IPageRendererProvider() {
@Override
public PageRenderer apply(RenderPageRequestHandler handler) {
return new WebPageRenderer(handler) {
@Override
protected boolean isOnePassRender() {
IRequestablePage page =
getRenderPageRequestHandler().getPage();
return page.isPageStateless() ||
page instanceof BrowserInfoPage || super.isOnePassRender();
}
};
}
});
I' working with wicket version 8.3.0.
Best regards
Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Best practice for custom page renderer
Posted by Alberto Brosich <ab...@inogs.it>.
Doing more investigations I found that the problem is gathering the
extended browser info. Omitting that, BrowserInfoPage is stateless.
Sorry for the noise.
Regards
Alberto
On Thu, 2019-02-28 at 11:06 +0100, Alberto Brosich wrote:
> On Thu, 2019-02-28 at 01:50 -0800, Bas Gooren wrote:
> > Hi!
> >
> > We have many stateless pages in our apps (public-facing, indexed,
> > e-
> > commerce websites), and use the default render strategy provided by
> > wicket.
> > When a page is stateless, wicket does not redirect.
> >
> > Are you sure your pages are stateless?
>
> Yes, I am sure.
> The problem could be that I'm using ClientInfo to collect info about
> clients for analytics purposes. It uses BrowserInfoPage that is
> stateful. For that reason I checked it in isOnePassRender() method.
>
> Is there a way to convert BrowserInfoPage to stateless?
> For example every page I create has a form to submit a search but I
> used a StatelessForm for that, therefore if a page does not contain
> any
> other stateful components or behaviors, it is stateless.
>
> Best regards
>
> Alberto
> > Met vriendelijke groet,
> > Kind regards,
> >
> > Bas Gooren
> >
> > Op 28 februari 2019 bij 10:48:25, Alberto Brosich (
> > abrosich@inogs.it)
> > schreef:
> > > Hello,
> > >
> > > I didn't find any useful information about that in the
> > > documentation.
> > >
> > > For some reasons (e.g. search engine bots or clients unable to
> > > follow
> > > redirects) on some pages I would like to have an http 200
> > > response.
> > > By
> > > default Wicket uses REDIRECT_TO_BUFFER render strategy that send
> > > a
> > > 302
> > > redirect first.
> > >
> > > Which is the best practice for use ONE_PASS_RENDER strategy?
> > >
> > > Is it reasonable to adopt ONE_PASS_RENDER for all stateless pages
> > > or is
> > > it better to change the render strategy only for specific pages?
> > >
> > > Is setPageRendererProvider() the good place where to handle
> > > that?
> > >
> > > For example:
> > >
> > > setPageRendererProvider( new IPageRendererProvider() {
> > >
> > > @Override
> > > public PageRenderer apply(RenderPageRequestHandler handler) {
> > > br/> return new WebPageRenderer(handler) {{
> > > br/> @@Override
> > > protected boolean isOnePassRender() {
> > > br/> IRequestablePage page =
> > > getRenderPageRequestHandler().getPage();
> > >
> > > return page.isPageStateless() ||
> > > page instanceof BrowserInfoPage || super.isOnePassRender();
> > > }
> > > };
> > > }
> > > });
> > >
> > > I' working with wicket version 8.3.0.
> > >
> > > Best regards
> > >
> > > Alberto
> > >
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Best practice for custom page renderer
Posted by Alberto Brosich <ab...@inogs.it>.
On Thu, 2019-02-28 at 01:50 -0800, Bas Gooren wrote:
> Hi!
>
> We have many stateless pages in our apps (public-facing, indexed, e-
> commerce websites), and use the default render strategy provided by
> wicket.
> When a page is stateless, wicket does not redirect.
>
> Are you sure your pages are stateless?
Yes, I am sure.
The problem could be that I'm using ClientInfo to collect info about
clients for analytics purposes. It uses BrowserInfoPage that is
stateful. For that reason I checked it in isOnePassRender() method.
Is there a way to convert BrowserInfoPage to stateless?
For example every page I create has a form to submit a search but I
used a StatelessForm for that, therefore if a page does not contain any
other stateful components or behaviors, it is stateless.
Best regards
Alberto
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 28 februari 2019 bij 10:48:25, Alberto Brosich (abrosich@inogs.it)
> schreef:
> > Hello,
> >
> > I didn't find any useful information about that in the
> > documentation.
> >
> > For some reasons (e.g. search engine bots or clients unable to
> > follow
> > redirects) on some pages I would like to have an http 200 response.
> > By
> > default Wicket uses REDIRECT_TO_BUFFER render strategy that send a
> > 302
> > redirect first.
> >
> > Which is the best practice for use ONE_PASS_RENDER strategy?
> >
> > Is it reasonable to adopt ONE_PASS_RENDER for all stateless pages
> > or is
> > it better to change the render strategy only for specific pages?
> >
> > Is setPageRendererProvider() the good place where to handle that?
> >
> > For example:
> >
> > setPageRendererProvider( new IPageRendererProvider() {
> >
> > @Override
> > public PageRenderer apply(RenderPageRequestHandler handler) {
> > br/> return new WebPageRenderer(handler) {{
> > br/> @@Override
> > protected boolean isOnePassRender() {
> > br/> IRequestablePage page =
> > getRenderPageRequestHandler().getPage();
> >
> > return page.isPageStateless() ||
> > page instanceof BrowserInfoPage || super.isOnePassRender();
> > }
> > };
> > }
> > });
> >
> > I' working with wicket version 8.3.0.
> >
> > Best regards
> >
> > Alberto
> >
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Best practice for custom page renderer
Posted by Bas Gooren <ba...@iswd.nl>.
Hi!
We have many stateless pages in our apps (public-facing, indexed,
e-commerce websites), and use the default render strategy provided by
wicket.
When a page is stateless, wicket does not redirect.
Are you sure your pages are stateless?
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 28 februari 2019 bij 10:48:25, Alberto Brosich (abrosich@inogs.it)
schreef:
Hello,
I didn't find any useful information about that in the documentation.
For some reasons (e.g. search engine bots or clients unable to follow
redirects) on some pages I would like to have an http 200 response. By
default Wicket uses REDIRECT_TO_BUFFER render strategy that send a 302
redirect first.
Which is the best practice for use ONE_PASS_RENDER strategy?
Is it reasonable to adopt ONE_PASS_RENDER for all stateless pages or is
it better to change the render strategy only for specific pages?
Is setPageRendererProvider() the good place where to handle that?
For example:
setPageRendererProvider( new IPageRendererProvider() {
@Override
public PageRenderer apply(RenderPageRequestHandler handler) {
br/> return new WebPageRenderer(handler) {{
br/> @@Override
protected boolean isOnePassRender() {
br/> IRequestablePage page =
getRenderPageRequestHandler().getPage();
return page.isPageStateless() ||
page instanceof BrowserInfoPage || super.isOnePassRender();
}
};
}
});
I' working with wicket version 8.3.0.
Best regards
Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org