Hi Francesco, I've just tried it and it works the way I wanted to change it: Now only the first behavior added to a component contributes the JS code that initializes the WS connection. Any other WSBehavior just adds itself to the component tree and later receives all messages (connect, message, close). I'll apply the change from my previous mail to WebSocketBehavior. Please create a ticket with a quickstart if your initial version still doesn't work (in case you want to revert to it!). Thanks for the discussion!
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Apr 22, 2016 at 9:40 AM, Martin Grigorov <[email protected]> wrote: > Hi, > > Thanks! > I'll debug it this weekend! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Fri, Apr 22, 2016 at 9:38 AM, Francesco Chicchiriccò < > [email protected]> wrote: > >> On 21/04/2016 21:23, Martin Grigorov wrote: >> >>> Hi, >>> >>> Could you please try this code: >>> >>> public abstract class MyWebSocketBehavior extends WebSocketBehavior >>> { >>> private final static MetaDataKey<Boolean> IS_ALREADY_INSTALLED = new >>> MetaDataKey<Boolean>() >>> {}; >>> >>> @Override >>> public void renderHead(Component component, IHeaderResponse response) >>> { >>> Page page = component.getPage(); >>> if (page.getMetaData(IS_ALREADY_INSTALLED) == null) >>> { >>> super.renderHead(component, response); >>> page.setMetaData(IS_ALREADY_INSTALLED, Boolean.TRUE); >>> } >>> } >>> } >>> >>> And then use MyWebSocketBehavior in your panels instead. >>> This way only the first one will contribute the JS to setup a WebSocket >>> connection but all of them will receive messages. >>> >> >> Hi Martin, >> it does not work unfortunately: still the only onConnect() method invoked >> is the one from the panel added in BasePage. >> >> FYI at the moment I have solved with this commit, which adds a single >> WebSocketBehavior to each page: >> >> >> https://github.com/apache/syncope/commit/c34416301b17b148e937390e05a17122b848888e#diff-fa61cf2d467a65609ff05fe60442faa3R91 >> >> Regards. >> >> >> On Thu, Apr 21, 2016 at 9:12 AM, Martin Grigorov <[email protected]> >>> wrote: >>> >>> On Thu, Apr 21, 2016 at 8:41 AM, Francesco Chicchiriccò < >>>> [email protected]> wrote: >>>> >>>> On 20/04/2016 17:58, Martin Grigorov wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> There is no point in having more than one WebSocket connections per >>>>>> page. >>>>>> And actually, Wicket Native WebSockets do not support it out of the >>>>>> box. >>>>>> The registry with the websocket connections at the server side uses a >>>>>> key >>>>>> <applicationName, sessionId, pageId> so there could be just one >>>>>> connection >>>>>> per page. >>>>>> >>>>>> Thanks for clarifying: this means I need to refactor our code so that >>>>> a >>>>> single WebSocketBehavior is added to every page, and then moving the >>>>> logic >>>>> for distinguishing what is actually to be performed inside its >>>>> onConnect() >>>>> method. >>>>> >>>>> Now the next problem is how to be notified when a message comes from >>>>> the >>>>> >>>>>> client, because the behavior is registered somewhere else and not in >>>>>> the >>>>>> current component... >>>>>> You could override component's #onEvent() and do something when the >>>>>> payload >>>>>> is TextMessage but this is not very user friendly :-/ >>>>>> Please create a ticket for improvement! >>>>>> >>>>>> Sorry, it is not clear to me what kind of improvement can be filed: >>>>> allowing multiple WebSocketBehaviors to a page? >>>>> I will anyway change our logic as outlined above, since I need to have >>>>> it >>>>> working with Wicket 7.20. >>>>> >>>>> The problem I see is that you will have code like: >>>> >>>> if (getBehaviors(WebSocketBehavior.class).isEmpty()) { >>>> add(new WebSocketBehavior() { >>>> @Override protected void onTextMessage(...) {...} >>>> }); >>>> } >>>> >>>> But the condition will pass for just one of the calls. >>>> All other calls won't execute the body of the 'if' and thus >>>> #onTextMessage() won't be called when there is a new message from the >>>> client. To be notified when a message comes you will have to override >>>> Component#onEvent(). >>>> I'll think on a solution to add the WSBehavior to the component tree but >>>> not create a client side WebSocket. I.e. it will be just a server side >>>> publisher/subscriber. >>>> >>>> >>>> Regards. >>>>> >>>>> >>>>> On Wed, Apr 20, 2016 at 9:16 AM, Francesco Chicchiriccò < >>>>> >>>>>> [email protected]> wrote: >>>>>> >>>>>> Hi Martin, >>>>>>> thanks for your prompt reply. >>>>>>> >>>>>>> Are you suggesting that the best practice is to add >>>>>>> WebSocketBehavior at >>>>>>> most once per page - and possibly to the page itself? >>>>>>> >>>>>>> My current situation is that I have defined three different anonymous >>>>>>> WebSocketBehavior instances, added to three different panels >>>>>>> [1][2][3]: >>>>>>> panel [1] is added to BasePage, panel [2] and [3] are added to >>>>>>> Dashboard, >>>>>>> extending BasePage. >>>>>>> >>>>>>> With this configuration, only the onConnect() method from [1] is >>>>>>> invoked. >>>>>>> >>>>>>> If instead I disable [1] (via the if reported below), both [2] and >>>>>>> [3] >>>>>>> onConnect() methods are invoked. >>>>>>> >>>>>>> So my actual issue it not really how to asses when to add [1] or not, >>>>>>> but >>>>>>> to have [1][2][3] all added to Dashboard, and [1] to the remaining >>>>>>> pages. >>>>>>> >>>>>>> Regards. >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> >>>>>>> https://github.com/apache/syncope/blob/master/client/console/src/main/java/org/apache/syncope/client/console/widgets/ApprovalsWidget.java#L179-L189 >>>>>>> [2] >>>>>>> >>>>>>> >>>>>>> https://github.com/apache/syncope/blob/master/client/console/src/main/java/org/apache/syncope/client/console/widgets/JobWidget.java#L119-L128 >>>>>>> [3] >>>>>>> >>>>>>> >>>>>>> https://github.com/apache/syncope/blob/master/client/console/src/main/java/org/apache/syncope/client/console/widgets/ReconciliationWidget.java#L144-L155 >>>>>>> >>>>>>> >>>>>>> On 19/04/2016 18:07, Martin Grigorov wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> You could use something like: >>>>>>>> >>>>>>>> if (getBehaviors(WebSocketBehavior.class).isEmpty()) { >>>>>>>> add(new WebSocketBehavior() {...}); >>>>>>>> } >>>>>>>> >>>>>>>> This way only one instance will be added to one page instance. >>>>>>>> >>>>>>>> Martin Grigorov >>>>>>>> Wicket Training and Consulting >>>>>>>> https://twitter.com/mtgrigorov >>>>>>>> >>>>>>>> On Tue, Apr 19, 2016 at 5:50 PM, Francesco Chicchiriccò < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>>> in the upcoming Syncope 2.0 we are enjoying WebSocketBehavior for >>>>>>>>> making >>>>>>>>> our admin console UI more reactive. >>>>>>>>> >>>>>>>>> It mostly works - thanks for this! - but we are experiencing some >>>>>>>>> troubles >>>>>>>>> lately. >>>>>>>>> >>>>>>>>> There is a class BasePage which is extended by all other pages, and >>>>>>>>> contains a panel which adds WebSocketBehavior. >>>>>>>>> One of such pages (Dashboard) also contains two panels, each of >>>>>>>>> which >>>>>>>>> adds >>>>>>>>> in turn WebSocketBehavior. >>>>>>>>> >>>>>>>>> I observe that when the first WebSocketBehavior (in BasePage) is >>>>>>>>> added, >>>>>>>>> the other two WebSocketBehavior instances' onConnect() method is >>>>>>>>> not >>>>>>>>> invoked at all. >>>>>>>>> >>>>>>>>> If instead, I do something like as following, in BasePage: >>>>>>>>> >>>>>>>>> if (!(pageRef.getPage() instanceof Dashboard)) { >>>>>>>>> add(new WebSocketBehavior() {...}); >>>>>>>>> } >>>>>>>>> >>>>>>>>> everything works as expected (naturally BasePages's >>>>>>>>> WebSocketBehavior >>>>>>>>> does >>>>>>>>> not come into play): both on Dashboard and other pages. >>>>>>>>> >>>>>>>>> Any hint? >>>>>>>>> TIA >>>>>>>>> >>>>>>>>> Regards. >>>>>>>>> >>>>>>>>> -- >> Francesco Chicchiriccò >> >> Tirasa - Open Source Excellence >> http://www.tirasa.net/ >> >> Involved at The Apache Software Foundation: >> member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer >> http://home.apache.org/~ilgrosso/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
