Re: WebSocketRequestHandler object not executing javascript code
On Thu, Feb 28, 2019 at 5:28 PM Matteo Alessandroni wrote: > > > On 28/02/19 15:11, Martin Grigorov wrote: > > Hi, > > > > I've explained you earlier where to look at. > > WebSocketRequestHandler#respond() is not called for some reason. > > It is scheduled in AbstractWebSocketProcessor with > > requestCycle#scheduleAfterCurrent() but it seems later another > > IRequestHandler is scheduled and replaced it. > > > > If you can reproduce in a mini application I would be happy to debug it. > > > > On Thu, Feb 28, 2019 at 3:51 PM Matteo Alessandroni < > skylar...@apache.org> > > wrote: > > Hi, > > our application is open source and you can easily reproduce the issue. > It is open source but it is not mini. My spare time is limited. If you'd like to pay for my services then I will debug the problem in the business hours. > If you are available to debug it, here are the simple steps to start > Syncope and reproduce the case: > > * Download source code from [1] e go to branch 2_1_X; > * Build and run it by running: > mvn -PskipTests,all && cd fit/enduser-reference && mvn -Pdebug; > * Go to http://localhost:9080/syncope-console/, login with "admin / > admin" and click on "Topology" from the left menu; > * Click on the first node from the bottom and select "Add new connector"; > * Fill the required fields (with "*") with random values, select > "net.tirasa.connid.bundles.soap" in the "Bundle *" dropdown and > click "Next"; > * Insert random values for the "Service Endpoint *" and "Service name > *" fields, click "Next" again, then click "Finish". A connector node > is now created; > > The issue is that the node should be visible as soon as the wizard > disappears (after finish), but, instead, it's not until you refresh the > page (e.g. click on "Topology" again). > The notable parts in the code are on [2] and [3] (as mentioned before). > > I really appreciate your help! > Thank you! > > [1] https://github.com/apache/syncope/tree/2_1_X > > [2] > > https://github.com/apache/syncope/blob/2_1_X/client/console/src/main/java/org/apache/syncope/client/console/topology/Topology.java#L602-L609 > > [3] > > https://github.com/apache/syncope/blob/2_1_X/client/console/src/main/java/org/apache/syncope/client/console/topology/TopologyWebSocketBehavior.java#L153-L158 > > > > > > >> > >> On 22/02/19 12:55, Matteo Alessandroni wrote: > >>> > >>> On 22/02/19 12:46, Martin Grigorov wrote: > On Fri, Feb 22, 2019 at 1:40 PM Matteo Alessandroni > > wrote: > > > On 22/02/19 12:28, Matteo Alessandroni wrote: > >> On 22/02/19 10:31, Martin Grigorov wrote: > >>> On Fri, Feb 22, 2019 at 10:50 AM Matteo Alessandroni > >>> > >>> wrote: > >>> > On 21/02/19 18:50, Martin Grigorov wrote: > > On Thu, Feb 21, 2019, 18:29 Matteo Alessandroni > > > wrote: > > > >> On 21/02/19 16:43, Martin Grigorov wrote: > >>> On Thu, Feb 21, 2019 at 5:35 PM Matteo Alessandroni < > >> skylar...@apache.org> > >>> wrote: > >>> > On 21/02/19 16:30, Martin Grigorov wrote: > > On Thu, Feb 21, 2019 at 5:24 PM Matteo Alessandroni < > skylar...@apache.org> > > wrote: > > > >> On 21/02/19 16:07, Martin Grigorov wrote: > >>> On Thu, Feb 21, 2019 at 4:41 PM Matteo Alessandroni < > >> skylar...@apache.org> > >>> wrote: > >>> > On 21/02/19 12:14, Martin Grigorov wrote: > > On Thu, Feb 21, 2019 at 12:11 PM Matteo Alessandroni < > > matteo.alessandr...@tirasa.net> wrote: > > > >> Hi, > >> > >> On 21/02/19 11:05, Martin Grigorov wrote: > >>> When the WebSocket connection is established (maybe > >>> when the > page > is > >>> loaded) you should see an entry in the Network tab. > >>> If you select this entry then on the right-side you > >>> should see > >> any > WS > >>> messages to/from the server. > >> Yes I know how about WS debugging, but I do not see any > WS > request > >> (with > >> WS devtool filter and without it). > >> > > Maybe this is the problem. > > If there is no WebSocket response at all then there is no > > way the > >> JS > >> code > > to be executed. > > > > But since your WebSocketBehavior callback method is > > executed then > there > > must be an established WebSocket connection. > > I have no idea what goes wrong. > It is strange because in our application version that uses
Re: WebSocketRequestHandler object not executing javascript code
On 28/02/19 15:11, Martin Grigorov wrote:
Hi,
I've explained you earlier where to look at.
WebSocketRequestHandler#respond() is not called for some reason.
It is scheduled in AbstractWebSocketProcessor with
requestCycle#scheduleAfterCurrent() but it seems later another
IRequestHandler is scheduled and replaced it.
If you can reproduce in a mini application I would be happy to debug it.
On Thu, Feb 28, 2019 at 3:51 PM Matteo Alessandroni
wrote:
Hi,
our application is open source and you can easily reproduce the issue.
If you are available to debug it, here are the simple steps to start
Syncope and reproduce the case:
* Download source code from [1] e go to branch 2_1_X;
* Build and run it by running:
mvn -PskipTests,all && cd fit/enduser-reference && mvn -Pdebug;
* Go to http://localhost:9080/syncope-console/, login with "admin /
admin" and click on "Topology" from the left menu;
* Click on the first node from the bottom and select "Add new connector";
* Fill the required fields (with "*") with random values, select
"net.tirasa.connid.bundles.soap" in the "Bundle *" dropdown and
click "Next";
* Insert random values for the "Service Endpoint *" and "Service name
*" fields, click "Next" again, then click "Finish". A connector node
is now created;
The issue is that the node should be visible as soon as the wizard
disappears (after finish), but, instead, it's not until you refresh the
page (e.g. click on "Topology" again).
The notable parts in the code are on [2] and [3] (as mentioned before).
I really appreciate your help!
Thank you!
[1] https://github.com/apache/syncope/tree/2_1_X
[2]
https://github.com/apache/syncope/blob/2_1_X/client/console/src/main/java/org/apache/syncope/client/console/topology/Topology.java#L602-L609
[3]
https://github.com/apache/syncope/blob/2_1_X/client/console/src/main/java/org/apache/syncope/client/console/topology/TopologyWebSocketBehavior.java#L153-L158
On 22/02/19 12:55, Matteo Alessandroni wrote:
On 22/02/19 12:46, Martin Grigorov wrote:
On Fri, Feb 22, 2019 at 1:40 PM Matteo Alessandroni
wrote:
On 22/02/19 12:28, Matteo Alessandroni wrote:
On 22/02/19 10:31, Martin Grigorov wrote:
On Fri, Feb 22, 2019 at 10:50 AM Matteo Alessandroni
wrote:
On 21/02/19 18:50, Martin Grigorov wrote:
On Thu, Feb 21, 2019, 18:29 Matteo Alessandroni
On 21/02/19 16:43, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 5:35 PM Matteo Alessandroni <
skylar...@apache.org>
wrote:
On 21/02/19 16:30, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 5:24 PM Matteo Alessandroni <
skylar...@apache.org>
wrote:
On 21/02/19 16:07, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 4:41 PM Matteo Alessandroni <
skylar...@apache.org>
wrote:
On 21/02/19 12:14, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 12:11 PM Matteo Alessandroni <
matteo.alessandr...@tirasa.net> wrote:
Hi,
On 21/02/19 11:05, Martin Grigorov wrote:
When the WebSocket connection is established (maybe
when the
page
is
loaded) you should see an entry in the Network tab.
If you select this entry then on the right-side you
should see
any
WS
messages to/from the server.
Yes I know how about WS debugging, but I do not see any WS
request
(with
WS devtool filter and without it).
Maybe this is the problem.
If there is no WebSocket response at all then there is no
way the
JS
code
to be executed.
But since your WebSocketBehavior callback method is
executed then
there
must be an established WebSocket connection.
I have no idea what goes wrong.
It is strange because in our application version that uses
Wicket
7.x
I
see no WS requests in DevTools console as well, but the
code is
correctly executed and everything works.
Yes the WebSocket connection seems to be established
anyway in
both
our
versions so with both Wicket 7.x and 8.x, but for some
reason the
"appendJavaScript()" method does not work on the
"WebSocketRequestHandler" object with Wicket 8.x.
Is there anything else we can try to make it work?
Put a breakpoint at
https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-core/src/main/java/org/apache/wicket/page/XmlPartialPageUpdate.java#L141
and see whether it is called.
And another one at
https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketResponse.java#L86
to see whether the XML response is being written back to the
browser
in
the
WebSocketConnection.
Thanks!
Ok the first method [1] was called many times and once was the
one
I'm
interested on where the "script" variable was:
"window.Wicket.WebSocket.send('{"kind":"ADD_ENDPOINT","target":"...","source":"...","scope":"..."}');"
also the second one [2] was called, but *only once* and
both the
"text"
and "binary" variables were null.
What is the type of "response" variable at
https://github.com/apache/wicke
Re: WebSocketRequestHandler object not executing javascript code
Hi,
I've explained you earlier where to look at.
WebSocketRequestHandler#respond() is not called for some reason.
It is scheduled in AbstractWebSocketProcessor with
requestCycle#scheduleAfterCurrent() but it seems later another
IRequestHandler is scheduled and replaced it.
If you can reproduce in a mini application I would be happy to debug it.
On Thu, Feb 28, 2019 at 3:51 PM Matteo Alessandroni
wrote:
>
>
> On 22/02/19 12:55, Matteo Alessandroni wrote:
> >
> >
> > On 22/02/19 12:46, Martin Grigorov wrote:
> >> On Fri, Feb 22, 2019 at 1:40 PM Matteo Alessandroni
> >>
> >> wrote:
> >>
> >>>
> >>> On 22/02/19 12:28, Matteo Alessandroni wrote:
>
> On 22/02/19 10:31, Martin Grigorov wrote:
> > On Fri, Feb 22, 2019 at 10:50 AM Matteo Alessandroni
> >
> > wrote:
> >
> >> On 21/02/19 18:50, Martin Grigorov wrote:
> >>> On Thu, Feb 21, 2019, 18:29 Matteo Alessandroni
> >>> >>> wrote:
> >>>
> On 21/02/19 16:43, Martin Grigorov wrote:
> > On Thu, Feb 21, 2019 at 5:35 PM Matteo Alessandroni <
> skylar...@apache.org>
> > wrote:
> >
> >> On 21/02/19 16:30, Martin Grigorov wrote:
> >>> On Thu, Feb 21, 2019 at 5:24 PM Matteo Alessandroni <
> >> skylar...@apache.org>
> >>> wrote:
> >>>
> On 21/02/19 16:07, Martin Grigorov wrote:
> > On Thu, Feb 21, 2019 at 4:41 PM Matteo Alessandroni <
> skylar...@apache.org>
> > wrote:
> >
> >> On 21/02/19 12:14, Martin Grigorov wrote:
> >>> On Thu, Feb 21, 2019 at 12:11 PM Matteo Alessandroni <
> >>> matteo.alessandr...@tirasa.net> wrote:
> >>>
> Hi,
>
> On 21/02/19 11:05, Martin Grigorov wrote:
> > When the WebSocket connection is established (maybe
> > when the
> >> page
> >> is
> > loaded) you should see an entry in the Network tab.
> > If you select this entry then on the right-side you
> > should see
> any
> >> WS
> > messages to/from the server.
> Yes I know how about WS debugging, but I do not see any WS
> >> request
> (with
> WS devtool filter and without it).
>
> >>> Maybe this is the problem.
> >>> If there is no WebSocket response at all then there is no
> >>> way the
> JS
> code
> >>> to be executed.
> >>>
> >>> But since your WebSocketBehavior callback method is
> >>> executed then
> >> there
> >>> must be an established WebSocket connection.
> >>> I have no idea what goes wrong.
> >> It is strange because in our application version that uses
> >> Wicket
> 7.x
> >> I
> >> see no WS requests in DevTools console as well, but the
> >> code is
> >> correctly executed and everything works.
> >> Yes the WebSocket connection seems to be established
> >> anyway in
> >> both
> >> our
> >> versions so with both Wicket 7.x and 8.x, but for some
> >> reason the
> >> "appendJavaScript()" method does not work on the
> >> "WebSocketRequestHandler" object with Wicket 8.x.
> >>
> >> Is there anything else we can try to make it work?
> >>
> > Put a breakpoint at
> >
> >>>
> https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-core/src/main/java/org/apache/wicket/page/XmlPartialPageUpdate.java#L141
> >>>
> > and see whether it is called.
> > And another one at
> >
> >>>
> https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketResponse.java#L86
> >>>
> > to see whether the XML response is being written back to the
> >> browser
> in
> the
> > WebSocketConnection.
> Thanks!
> Ok the first method [1] was called many times and once was the
> one
> >> I'm
> interested on where the "script" variable was:
>
>
>
> >>>
> "window.Wicket.WebSocket.send('{"kind":"ADD_ENDPOINT","target":"...","source":"...","scope":"..."}');"
>
> >>>
> >>>
> also the second one [2] was called, but *only once* and
> both the
> "text"
> and "binary" variables were null.
>
> >>> What is the type of "response" variable at
> >>>
> >>>
> https://github.com/apache/wicket/blob/3704
Re: WebSocketRequestHandler object not executing javascript code
On 22/02/19 12:55, Matteo Alessandroni wrote:
On 22/02/19 12:46, Martin Grigorov wrote:
On Fri, Feb 22, 2019 at 1:40 PM Matteo Alessandroni
wrote:
On 22/02/19 12:28, Matteo Alessandroni wrote:
On 22/02/19 10:31, Martin Grigorov wrote:
On Fri, Feb 22, 2019 at 10:50 AM Matteo Alessandroni
wrote:
On 21/02/19 18:50, Martin Grigorov wrote:
On Thu, Feb 21, 2019, 18:29 Matteo Alessandroni
wrote:
On 21/02/19 16:43, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 5:35 PM Matteo Alessandroni <
skylar...@apache.org>
wrote:
On 21/02/19 16:30, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 5:24 PM Matteo Alessandroni <
skylar...@apache.org>
wrote:
On 21/02/19 16:07, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 4:41 PM Matteo Alessandroni <
skylar...@apache.org>
wrote:
On 21/02/19 12:14, Martin Grigorov wrote:
On Thu, Feb 21, 2019 at 12:11 PM Matteo Alessandroni <
matteo.alessandr...@tirasa.net> wrote:
Hi,
On 21/02/19 11:05, Martin Grigorov wrote:
When the WebSocket connection is established (maybe
when the
page
is
loaded) you should see an entry in the Network tab.
If you select this entry then on the right-side you
should see
any
WS
messages to/from the server.
Yes I know how about WS debugging, but I do not see any WS
request
(with
WS devtool filter and without it).
Maybe this is the problem.
If there is no WebSocket response at all then there is no
way the
JS
code
to be executed.
But since your WebSocketBehavior callback method is
executed then
there
must be an established WebSocket connection.
I have no idea what goes wrong.
It is strange because in our application version that uses
Wicket
7.x
I
see no WS requests in DevTools console as well, but the
code is
correctly executed and everything works.
Yes the WebSocket connection seems to be established
anyway in
both
our
versions so with both Wicket 7.x and 8.x, but for some
reason the
"appendJavaScript()" method does not work on the
"WebSocketRequestHandler" object with Wicket 8.x.
Is there anything else we can try to make it work?
Put a breakpoint at
https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-core/src/main/java/org/apache/wicket/page/XmlPartialPageUpdate.java#L141
and see whether it is called.
And another one at
https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketResponse.java#L86
to see whether the XML response is being written back to the
browser
in
the
WebSocketConnection.
Thanks!
Ok the first method [1] was called many times and once was the
one
I'm
interested on where the "script" variable was:
"window.Wicket.WebSocket.send('{"kind":"ADD_ENDPOINT","target":"...","source":"...","scope":"..."}');"
also the second one [2] was called, but *only once* and
both the
"text"
and "binary" variables were null.
What is the type of "response" variable at
https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-core/src/main/java/org/apache/wicket/page/XmlPartialPageUpdate.java#L141
?
It seems it is not WebSocketResponse
Ideed, it's "StringResponse"!
And it's content is something like this:
I didn't expect this!
Can you please put a breakpoint
at org.apache.wicket.response.StringResponse#StringResponse()
(the
constructor) and see where it is instantiated.
AjaxRequestHandler uses StringResponse, but
WebSocketRequestHandler
does
not.
I'm not completely sure but it seems that all the times the
application
enters in [1] (including when "script" contains "addEnpoint(...)")
and
then the "StringResponse()" constructor is called, the source
is [2].
[1]
https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-core/src/main/java/org/apache/wicket/page/XmlPartialPageUpdate.java#L141
[2]
https://github.com/apache/wicket/blob/3704144b73521c6b10de5fa7864773230762e86c/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxRequestHandler.java#L360
It seems WebSocketRequestHandler#respond() is not called at all.
Put a breakpoint in AbstractWebSocketProcessor and see what happens
there.
Hi,
ok thanks, I did that and the constructor of
"AbstractWebSocketProcessor" is never called!
The constructor should be called when the WS connection is
established.
I guess you use wicket-native-websocket-javax.
Check org.apache.wicket.protocol.ws.javax.JavaxWebSocketProcessor and
its
org.apache.wicket.protocol.ws
.javax.JavaxWebSocketProcessor.StringMessageHandler
onMessage() method is called when the client sends something to the
server.
onMessage() delegates
to
org.apache.wicket.protocol.ws
.api.AbstractWebSocketProcessor#broadcastMessage()
where the processing happens, i.e. WebSocketBehavior#onMessage() is
called.
Yes we use "wicket-native-websocket-javax" [1].
What I have just done is putting a breackpoint in both that method
from
"org.
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
