Button over websockets

26 views
Skip to first unread message

Maxim Solodovnik

unread,
Sep 13, 2014, 2:32:49 AM9/13/14
to wicket-j...@googlegroups.com
Hello Sebastien,

I'm trying to use WebSockets in our projects (wicket7-M3)
I'm adding com.googlecode.wicket.jquery.ui.form.button.Button with .setOutputMarkupPlaceholderTag(true).setVisible(false)
Then send it to WebSocketRequestHandler with updated visibility.

The weird thing I'm observing: Button visibility is updated, but it is not jquery-ui button (no css classes)

Am I doing something wrong? Or maybe you know how to fix it?

Thanks in advance

Sebastien

unread,
Sep 13, 2014, 4:22:31 AM9/13/14
to wicket-j...@googlegroups.com
Hi Maxim,

I would say it is supposed to work. Could you prepare me a quickstart so I can have a look?

Thanks in advance,
Sebastien.


--
You received this message because you are subscribed to the Google Groups "wicket-jquery-ui" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wicket-jquery-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wicket-jquery-ui/7d6d42d7-4c8c-4293-8471-8913a9ae4e9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Maxim Solodovnik

unread,
Sep 13, 2014, 4:40:05 AM9/13/14
to wicket-j...@googlegroups.com
sure, I'll try give me minute

--
You received this message because you are subscribed to a topic in the Google Groups "wicket-jquery-ui" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wicket-jquery-ui/fw6TdyO5o18/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wicket-jquery-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wicket-jquery-ui/CAAJwaYWhgcs%3DLfrVknVtiYX3tcf86MH1yJFQqmQzrT648L%2BboA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
WBR
Maxim aka solomax

Maxim Solodovnik

unread,
Sep 13, 2014, 6:08:48 AM9/13/14
to wicket-j...@googlegroups.com

Sebastien

unread,
Sep 13, 2014, 8:28:23 AM9/13/14
to wicket-j...@googlegroups.com
Hi Maxim,

The javascript block is correctly sent, and executed:
try{jQuery(function() { jQuery('#button4').button({ }); });}catch(e){Wicket.Log.error(e);}

However, it's seems that it is executed *before* the dom is ready again, meaning the button has not yet been added to the dom when the js is executed (note that calling #button() on a non existing dom element does not lead to an error).

So at this stage, I don't know if the resolution is in my hands, we should ask an expert whether or not it's the normal behavior (@martin, I think you are targeted! ;) )

Just little comments in the quickstart:
- you did not add CSSs
        <dependency>
            <groupId>com.googlecode.wicket-jquery-ui</groupId>
            <artifactId>wicket-jquery-ui-theme-uilightness</artifactId>
            <version>${wicket.version}</version>
        </dependency>

- The socket is pushed too quickly, before opening the connection::
response.render(OnDomReadyHeaderItem.forScript("window.setTimeout(function() {" +  aab.getCallbackScript() + "} ,500);"));

I've updated the quickstart with the comments above and sent you a PR.

Thanks & best regards,
Sebastien.

Maxim Solodovnik

unread,
Sep 13, 2014, 8:49:10 AM9/13/14
to wicket-j...@googlegroups.com
I'm not sure why it is necessary to add commented stylesheet :) maybe it can be removed?
In my original code theme is included :)

I thought dom is ready since I'm using OnDomReadyHeaderItem
I would like more generic solution, 500ms might be too few or too much depending on page complexity etc.

Sebastien

unread,
Sep 13, 2014, 9:12:47 AM9/13/14
to wicket-j...@googlegroups.com
Hi Maxim,

I'm not sure why it is necessary to add commented stylesheet :) maybe it can be removed?
Was for testing purpose, in case the css dynamic load was not taken into account. It might be good to leave it for further/future testing
 
In my original code theme is included :)
I've supposed so :)


I thought dom is ready since I'm using OnDomReadyHeaderItem
This OnDomReadyHeaderItem is to trigger the ajax behavior, not the push
 
I would like more generic solution, 500ms might be too few or too much depending on page complexity etc.
I did it just to make the quickstart work. I suppose it will work differently in a "real" use case (ie: the subscription is done differently than using an ajax bahavior)
 


On Saturday, 13 September 2014 19:28:23 UTC+7, Sebastien Briquet wrote:
Hi Maxim,

The javascript block is correctly sent, and executed:
try{jQuery(function() { jQuery('#button4').button({ }); });}catch(e){Wicket.Log.error(e);}

However, it's seems that it is executed *before* the dom is ready again, meaning the button has not yet been added to the dom when the js is executed (note that calling #button() on a non existing dom element does not lead to an error).

So at this stage, I don't know if the resolution is in my hands, we should ask an expert whether or not it's the normal behavior (@martin, I think you are targeted! ;) )

Just little comments in the quickstart:
- you did not add CSSs
        <dependency>
            <groupId>com.googlecode.wicket-jquery-ui</groupId>
            <artifactId>wicket-jquery-ui-theme-uilightness</artifactId>
            <version>${wicket.version}</version>
        </dependency>

- The socket is pushed too quickly, before opening the connection::
response.render(OnDomReadyHeaderItem.forScript("window.setTimeout(function() {" +  aab.getCallbackScript() + "} ,500);"));

I've updated the quickstart with the comments above and sent you a PR.

Thanks & best regards,
Sebastien.

--
You received this message because you are subscribed to the Google Groups "wicket-jquery-ui" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wicket-jquery-...@googlegroups.com.

Maxim Solodovnik

unread,
Sep 13, 2014, 9:25:51 AM9/13/14
to wicket-j...@googlegroups.com
>> This OnDomReadyHeaderItem is to trigger the ajax behavior, not the push
so the execution order should be:
1) dom ready
2) ajax behavior triggered
3) on response WebsocketMessage is pushed
4) component get message
5) component changes button visibility
The styles are not applied in your code as well :(

ps In my actual code websocket connection is opened steps before message is pushed (I hope so, will double check)

Sebastien

unread,
Sep 13, 2014, 9:50:42 AM9/13/14
to wicket-j...@googlegroups.com
6) javascript is sent to the client
8) javascript is executed (which applies the style... but the element does not exists)
9) button is added to the dom

steps 8 & 9 should be inversed. I don't know if it's our responsibility or the websocket's one...
I know my code is not working as well; the purpose of the update was to make the quickstart easier... to start, in case someone else want to join the party :)






Sebastien

unread,
Sep 13, 2014, 12:31:39 PM9/13/14
to wicket-j...@googlegroups.com
Hi Maxim

I have a workaround for your specific use case:

#ctor
        this.btn = new Button("button");
        // this.btn.setOutputMarkupPlaceholderTag(true).setVisible(false);
        this.btn.add(new DisplayNoneBehavior()); // workaround
        this.add(this.btn);

#onEvent
        if (event.getPayload() instanceof WebSocketPushPayload)
        {
            WebSocketPushPayload wsEvent = (WebSocketPushPayload) event.getPayload();
            WebSocketRequestHandler handler = wsEvent.getHandler();
            // handler.add(this.btn.setVisible(true));
            handler.appendJavaScript(String.format("jQuery('#%s').button().show();", this.btn.getMarkupId())); // workaround:
        }


But I have another serious concern with websockets:
Even WebSocketRequestHandler IS-A AjaxRequestTarget, RequestCycle.get().find(AjaxRequestTarget.class) returns null.
I don't know if it is intended or if it's a wicket issue (WebSocketRequestHandler having being implemented after AjaxRequestTarget)


So to recap the 2 concerns/issues:
1/ inserted script is executed *before* dom elements insertion.
2/ RequestCycle.get().find(AjaxRequestTarget.class) return null instead of the WebSocketRequestHandler instance.



Maxim Solodovnik

unread,
Sep 13, 2014, 12:41:05 PM9/13/14
to wicket-j...@googlegroups.com
I guess I need to ask expert :)
Hopefully Martin can answer all these questions

Martin Grigorov

unread,
Sep 15, 2014, 4:16:31 AM9/15/14
to wicket-j...@googlegroups.com
Hi,

I'll take a look later this week.
Is there a summarized info how to reproduce the issue ?

Sebastien

unread,
Sep 15, 2014, 4:18:36 AM9/15/14
to wicket-j...@googlegroups.com
Hi Martin,

Thanks in advance! Yes, the quickstart on Maxim's gihub is ready to be used...

Best regards,
Sebastien

Martin Grigorov

unread,
Sep 16, 2014, 3:23:39 AM9/16/14
to wicket-j...@googlegroups.com
How do you start the app ?
Because Start.java fails with :

java.lang.IllegalStateException: Websockets not supported on blocking connectors
at org.eclipse.jetty.websocket.WebSocketFactory.upgrade(WebSocketFactory.java:237)
at org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket(WebSocketFactory.java:396)
at org.apache.wicket.protocol.ws.jetty.Jetty7WebSocketFilter.acceptWebSocket(Jetty7WebSocketFilter.java:74)
at org.apache.wicket.protocol.ws.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:55)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
        ....

Don't tell me that you deploy it as .war :-)

--
You received this message because you are subscribed to the Google Groups "wicket-jquery-ui" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wicket-jquery-...@googlegroups.com.

Maxim Solodovnik

unread,
Sep 16, 2014, 3:26:07 AM9/16/14
to wicket-j...@googlegroups.com
I'm using "mvn jetty:run"
works as expected :)

Sebastien

unread,
Sep 16, 2014, 3:28:53 AM9/16/14
to wicket-j...@googlegroups.com

Hi Martin,

Yes, that's another point :)
mvn jetty:run is working

Best regards,
Sebastien

Martin Grigorov

unread,
Sep 16, 2014, 7:34:33 AM9/16/14
to wicket-j...@googlegroups.com
I've found the issue.
It is in wicket-native-websocket-core module.
But I have some other work now and I'll fix it later today or tomorrow.

Maxim Solodovnik

unread,
Sep 16, 2014, 7:42:54 AM9/16/14
to wicket-j...@googlegroups.com
Great news!
Thanks a lot!

Martin Grigorov

unread,
Sep 17, 2014, 8:46:57 AM9/17/14
to wicket-j...@googlegroups.com

Maxim Solodovnik

unread,
Sep 17, 2014, 9:00:51 AM9/17/14
to wicket-j...@googlegroups.com
Thanks Martin!
I can confirm: the example work as expected now :)

Sebastien Briquet

unread,
Sep 17, 2014, 9:02:06 AM9/17/14
to wicket-j...@googlegroups.com
Thanks a million too, Martin! :)

Martin Grigorov

unread,
Sep 17, 2014, 9:06:08 AM9/17/14
to wicket-j...@googlegroups.com
An extra feature added with this refactoring is that now IRequestCycleListeners are notified when WebSocket message is processed.

While it is more consistent with the rest of the request processing in Wicket I am in doubt whether it is not too much.

Sebastien

unread,
Sep 17, 2014, 9:12:10 AM9/17/14
to wicket-j...@googlegroups.com
Martin,

An extra feature added with this refactoring is that now IRequestCycleListeners are notified when WebSocket message is processed. 

While it is more consistent with the rest of the request processing in Wicket I am in doubt whether it is not too much.

Do you mean too much in term of features? I don't have a use case in mind, but I would say if it's consistent with the rest of the request processing, it should not be too much, IMO.

Sebastien

Maxim Solodovnik

unread,
Sep 17, 2014, 9:13:13 AM9/17/14
to wicket-j...@googlegroups.com
I'll try to test more WS features and maybe will provide additional feedback :)

Martin Grigorov

unread,
Sep 17, 2014, 9:25:57 AM9/17/14
to wicket-j...@googlegroups.com
On Wed, Sep 17, 2014 at 4:12 PM, Sebastien <seb...@gmail.com> wrote:
Martin,

An extra feature added with this refactoring is that now IRequestCycleListeners are notified when WebSocket message is processed. 

While it is more consistent with the rest of the request processing in Wicket I am in doubt whether it is not too much.

Do you mean too much in term of features? I don't have a use case in mind, but I would say if it's consistent with the rest of the request processing, it should not be too much, IMO.

My understanding is that WebSockets should be used for real-time communication. I.e. send back and forth many short messages.
Now for each received message at the server side will lead to notifying all registered IRCListeners - onBeginRequest, onRequestHandlerResolved/Scheduled, onEndRequest, etc.
I am not sure whether applications will actually need this.
But it will be useful for apps which use patterns like OpenSessionInView (onBeginRequest/onEndRequest) for example.

We'll see...
 

Sebastien


On Wed, Sep 17, 2014 at 4:02 PM, Sebastien Briquet <seb...@gmail.com> wrote:
Thanks a million too, Martin! :)


On Wednesday, September 17, 2014 3:00:51 PM UTC+2, Maxim Solodovnik wrote:
Thanks Martin!
I can confirm: the example work as expected now :)

On Wednesday, 17 September 2014 19:46:57 UTC+7, Martin Grigorov wrote:


--
You received this message because you are subscribed to the Google Groups "wicket-jquery-ui" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wicket-jquery-...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages