>
>
> 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.
>
> EB: Again, I don't see the motivation for having any kind of correspondance
> EB: between an <f:socket> tag and a specific UIComponent instance. I must
> EB: be missing something. Can someone please reply with a use case showing
> EB: the need for such a correspondence?
>
> The intention of this response was to indicate that the f:socket component
> would abstract away the transport implementation. The user should not have
> to worry about what is being used behind the scenes...it should simply
> work. So yes, I think it should provide a uniform abstraction, regardless
> of the transport.
>
I like the idea of having it "just work". However, there are some
situations where you may want to force (or at least specify a preference
for) a particular transport. We should allow that.
>
>
> On Mon, Aug 24, 2015 at 8:27 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>
>> 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
>>>
>>
>>
>