Re: Best practice for custom page renderer
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 ( > > abros...@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-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for custom page renderer
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 (abros...@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-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for custom page renderer
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 (abros...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org