jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [JAVASERVERFACES-SPEC_PUBLIC-1396] f:socket for SSE and WebSocket PROPOSAL

From: Edward Burns <edward.burns_at_oracle.com>
Date: Mon, 24 Aug 2015 05:31:16 -0700

Executive Summary: Ed cites discussion thus far and concludes our next
step is to answer this question: How does this feature interact with the
JSF request processing lifecycle? In Ed's thinking, it does not. Ed
asks Cagatay (or anyone else who knows the answer) to explain how this
works for PrimeFaces p:socket.

On Wed, Aug 12, 2015 at 9:14 PM, Edward Burns <edward.burns_at_oracle.com> wrote:

EB> 1. The only supported transports are WebSocket and SSE. If you don't
EB> manually specify a transport attribute, WebSocket is assumed. If the
EB> browser doesn't support WebSocket, it automatically falls back to SSE.
EB> If the browser doesn't support SSE, the tag is a no-op.

>>>>> On Thu, 13 Aug 2015 11:12:10 +0200, Bauke Scholtz <balusc_at_gmail.com> said:

B> 1. SSE can't receive messages from the client side whilw WS can. So I
B> gather that this is intented as one-way server-to-client push, and that the
B> enduser has to exclusively use ajax to send data back. This can perhaps be
B> clarified in the description.

Would your request be satisfied if there was a usage example in the
JavaDoc showing each kind of transport in action? My point in bringing
it up to the EG was just to make it clear that we are supporting less
than what PrimeFaces offers.

>>>>> On Sat, 15 Aug 2015 10:52:03 -0500, Josh Juneau <juneau001_at_gmail.com> said:

JJ> - Since SSE is one-way, perhaps the use of f:socket would vary depending
JJ> upon the chosen transport. Therefore, if WebSockets is specified (default)
JJ> then the communication would automatically be two-way, whereas when SSE is
JJ> chosen then it is a one-way street.

I gathered that the intent of p:socket was to provide a uniform
abstraction regardless of the transport. Is that not the case?

EB> 2. I opted not to have a corresponding UIComponent, whereas in
EB> PrimeFaces there is a corresponding UIComponent and Renderer [3]. I am
EB> taking f:ajax as a model in this regard. I'd like to hear from Cagatay
EB> why he found it necessary to have a backing UIComponent.

This is my first attempt at asking the question from the executive
summary.

B> 2. Perfectly reasonable. I only wonder about the corresponding JS file.
B> Should all the logic end up in the existing javax.faces:jsf.js? Or should
B> there be a new javax.faces:socket.js or push.js or so?

I'd like to hear from Cagatay on this, but I was expecting the script in
this case would be generated and inserted inline where it was needed at
each callsite.

JJ> - Given that there will be no UIComponent to accompany the new feature,
JJ> the chosen transport could then drive the type of UICompnent that will be
JJ> used by the developer. For instance, a WebSocket transport could utilize a
JJ> UIInput, whereas an SSE could utilize a UIOutput component only.

Again, I don't see the motivation for having any kind of correspondance
between an <f:socket> tag and a specific UIComponent instance. I must
be missing something. Can someone please reply with a use case showing
the need for such a correspondence?

MM> It seems to be natural to connect a socket (I personally would prefer
MM> "f:channel" over "f:socket" because this is neutral whereas "socket"
MM> implies websocket ousting SSE as fallback) to a UIComponent. The
MM> approach as discussed so far, allows the user to connect it (like
MM> f:ajax) to any UIComponent. And it should be possible to connect SSE to
MM> a input element too, although this channel provides a one way connection
MM> only.

MM> But what about non-UIComponents? Shall we consider that a JSF user might
MM> "connect" it to some client side (JavaScript) object?

MM> And, should it be implemented as a tag only? Thinking of HTML friendly
MM> coding, it would be great, to implement it as HTML attribute also (same
MM> thoughts might be applied to other tags):

MM> <h:inputText ...>
MM> <f:socket.../>
MM> </h:inputText>

B> What exactly would this do?

B> To me, it would make more sense if it was the other way round as it's push,
B> not pull. E.g.

B> <f:socket>
B> <h:outputText value="#{bean.message}" />
B> </f:socket>

B> or perhaps even

B> <f:socket ... render="foo" />
B> ...
B> <h:panelGroup id="foo">
B> <h:outputText value="#{bean.message}" />
B> </h:panelGroup>

B> This only requires reusing partial rendering as done by <f:ajax> in some
B> way and that's so far not covered by <p:socket> and the vdldoc. But it
B> would definitely reduce JS boilerplate to update the HTML DOM.

I see. Bauke, so is it fair to say that you see the usage of this
feature as just another way to get DOM updates from the server to the
client and vice versa? If that's the case, it seems like f:socket would
just be a replacement for f:ajax.

MM> Now, using HTML friendly style, a tag seems to pollute the HTML:

MM> <input type="text" jsf:value=...>
MM> <f:socket.../>
MM> </input>

MM> In my opinion, this integrates much better into HTML:

MM> <input type="text" jsf:value=... jsf:socket.../>

MM> Can we implement this feature (as well as elder ones) as attribute
MM> beside the tag implementation?

>>>>> On Thu, 20 Aug 2015 22:24:42 +0300, Cagatay Civici <cagatay.civici_at_gmail.com> said:

CC> I also like f:channel name instead of f:socket.

We can certainly change the name.

CC> A component is not strictly necessary but we definitely need an easy
CC> to use client side api to connect and send messages. Bauke
CC> summarized this really well.

How are people using p:socket currently? How does the communication
opened up by p:socket interact with the JSF Request Processing
Lifecycle?

EB> 3. There is no widgetVar, since that concept does not exist in core JSF.

B> 3. WidgetVar is in PF primarily necessary to be able to connect via
B> JavaScript when autoconnect=false. How could this now otherwise be done? I
B> think we can better support e.g. <f:socket var="foo"> and make it available
B> via a JS object property of jsf object in JS like so jsf.socket.foo (where
B> jsf.socket is an {} ). This way the developer can do e.g.
B> jsf.socket.foo.connect(). It would also be nice if the API can guarantee
B> uniqueness of this variable name and throw exception (or perhaps warning)
B> on duplicates.

Bauke, can you provide a little sketch here in email of how this would
look?

EB> 4. there is no rendered attribute, since there is no UIComponent.

B> 4. Developers can always wrap in a <c:if> to conditionally add it to the
B> view. However, the <f:ajax> and <f:param> have both a disable(d) attribute.
B> I'd imagine developers would intuitively expect the same on <f:socket> too.

Hmm, I get the sense that you are expecting that, like <f:ajax>,
<f:socket> is bound to a specific component. I didn't think that
<p:socket> worked that way, and I wasn't thinking <f:socket> would work
that way either.

Thanks for everyone who responded. Let's keep it going.

Thanks,

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 52 Business days til JavaOne 2015
| 67 Business days til DOAG 2015