Hi,
MM> Or am I to stupid to get the real intention?
Given that SSE must be supported, I gather that f:socket won't pull. That
shouldn't be a big problem as we already have f:ajax for that.
In a nutshell:
f:socket is push only (async from server to client).
f:ajax is pull only (async from client to server).
In a hindsight, that integrates also much easier in JSF lifecycle (view
scope, etc).
Cheers, B
On Mon, Aug 24, 2015 at 2:31 PM, Edward Burns <edward.burns_at_oracle.com>
wrote:
> 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
>