3

I have several panels, each displaying some contents, and zero, one, or more of these panels can be displayed, as in the following example:

<div jsf:id="contents">
    <ui:fragment rendered="#{aContent.rendered}">
        <h:form>
            <o:socket channel="a-channel" onmessage"onAMessage"/>
            <o:commandScript name="onAMessage"
                             actionListener=#{aContent.update()}"
                             render=":aComponent"/>
        </h:form>
        <my:aComponent id="aComponent" />
    </ui:fragment>

    <ui:fragment rendered="#{bContent.rendered}">
        <h:form>
            <o:socket channel="b-channel" onmessage"onBMessage"/>
            <o:commandScript name="onBMessage"
                             actionListener=#{bContent.update()}"
                             render=":bComponent"/>
        </h:form>
        <my:bComponent id="bComponent" />
    </ui:fragment>
</div>

I would like to know what happens to the client side web socket when one of these UI fragments is removed from the DOM after an AJAX update of the enclosing element.

Is the web socket closed? Should I consider another approach?

Stéphane Appercel
  • 1,427
  • 2
  • 13
  • 21

1 Answers1

3

Based on how it's currently implemented, it'll keep running. You need to repeat the condition in the connected attribute. 

<ui:fragment rendered="#{aContent.rendered}">
     <o:socket ... connected="#{aContent.rendered}" />

Perhaps this will be improved later when I plan to add <f:ajax> support for <o:socket>.

On the other hand, your code snippet is non-DRY. Try restricting to only 1 socket+commandScript combination which does its job dynamically based on contents of the pushed message. See also Channel design hints section of the documentation.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thanks BalusC. Your plan to add support for looks great. Is there any chance that this implementation may include the plumbing for basic notification like so as to use constructs like where a, b, c would be basic notification messages (just strings)? See also: http://stackoverflow.com/questions/39533247/dispatching-web-socket-messages-to-refresh-exactly-what-i-want-in-a-generic-way – Stéphane Appercel Sep 28 '16 at 08:19
  • Yes, that is the intent. – BalusC Sep 28 '16 at 08:22
  • That's great news :) Last thing but not the least: I agree with you that having only one web socket channel in the view is a good practice. But then it would be just great to have a mean to add an event observer in a composite component, just like the CDI @observes pattern, and upon reception of the event, the composite component would only refresh what's needed instead of the whole component. Experimental tests I made with a pure JavaScript approach show that I can reduce the network traffic by 50% up to 70% during an update, just because 50% to 70% of the composite component is static HTML – Stéphane Appercel Sep 28 '16 at 08:41