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.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
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]
>>
>>
>
