I think my previous response was not communicated correctly. I do not
believe that f:socket (or f:channel) would need to be bound to a
UIComponent.
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.
Thanks
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
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
>>
>
>