To All-
I think the proposed architecture sounds excellent, taking both Edward and
Bauke's ideas into account. My suggestion with regards to the difference
between SSE and WebSocket:
- Since SSE is one-way, perhaps the use of f:socket would vary depending
upon the chosen transport. Therefore, if WebSockets is specified (default)
then the communication would automatically be two-way, whereas when SSE is
chosen then it is a one-way street.
- Given that there will be no UIComponent to accompany the new feature,
the chosen transport could then drive the type of UICompnent that will be
used by the developer. For instance, a WebSocket transport could utilize a
UIInput, whereas an SSE could utilize a UIOutput component only.
Just my thoughts, hope it helps. Thanks
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Thu, Aug 13, 2015 at 4:12 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> Hi,
>
> Good start.
>
> 1. SSE can't receive messages from the client side whilw WS can. So I
> gather that this is intented as one-way server-to-client push, and that the
> enduser has to exclusively use ajax to send data back. This can perhaps be
> clarified in the description.
>
> 2. Perfectly reasonable. I only wonder about the corresponding JS file.
> Should all the logic end up in the existing javax.faces:jsf.js? Or should
> there be a new javax.faces:socket.js or push.js or so?
>
> 3. WidgetVar is in PF primarily necessary to be able to connect via
> JavaScript when autoconnect=false. How could this now otherwise be done? I
> think we can better support e.g. <f:socket var="foo"> and make it available
> via a JS object property of jsf object in JS like so jsf.socket.foo (where
> jsf.socket is an {} ). This way the developer can do e.g.
> jsf.socket.foo.connect(). It would also be nice if the API can guarantee
> uniqueness of this variable name and throw exception (or perhaps warning)
> on duplicates.
>
> 4. Developers can always wrap in a <c:if> to conditionally add it to the
> view. However, the <f:ajax> and <f:param> have both a disable(d) attribute.
> I'd imagine developers would intuitively expect the same on <f:socket> too.
>
> Cheers, B
>
>
> On Wed, Aug 12, 2015 at 9:14 PM, Edward Burns <edward.burns_at_oracle.com>
> wrote:
>
>> Hello Volunteers,
>>
>> After some preparatory steps [1] I have a first draft of the f:socket
>> vdldoc in our -SNAPSHOT build [2].
>>
>> There are some significant differences between this and the primefaces
>> p:socket on which it is based. Let me state those first and foremost so
>> we can get agreement that these differences are acceptable or not.
>>
>> 1. The only supported transports are WebSocket and SSE. If you don't
>> manually specify a transport attribute, WebSocket is assumed. If the
>> browser doesn't support WebSocket, it automatically falls back to SSE.
>> If the browser doesn't support SSE, the tag is a no-op.
>>
>> I am intenionally leaving atmosphere and jsonp out of the picture
>> because they complicate things too much. I could possibly be persuaded
>> to bring back jsonp but only because there is a Java EE 8 spec for it.
>>
>> 2. I opted not to have a corresponding UIComponent, whereas in
>> PrimeFaces there is a corresponding UIComponent and Renderer [3]. I am
>> taking f:ajax as a model in this regard. I'd like to hear from Cagatay
>> why he found it necessary to have a backing UIComponent.
>>
>> 3. There is no widgetVar, since that concept does not exist in core JSF.
>>
>> 4. there is no rendered attribute, since there is no UIComponent.
>>
>> Are all of the above acceptable? If not, please propose alternatives.
>>
>> Thanks,
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | 59 Business days til JavaOne 2015
>> | 74 Business days til DOAG 2015
>>
>> [1] We had been using TLDDoc to generate the vdl docs, even for the
>> facelets taglibs. This means we had to manually maintain .tld files
>> solely for the purpose of generating the documentation, even though the
>> .taglib.xml files were the normative artifacts. This manual maintenence
>> lead to some bitrot, which I had to fix in the cc: and f: libraries.
>> This work is being done under JAVASERVERFACES_SPEC_PUBLIC-1107. In
>> addition, I requested Zeef to enhance VDLDoc to allow passing in our
>> jsf-api.css file to get my beloved color coded changebars and watermark
>> as well as suppressing the "generated by VDLDoc" banner. Thanks to
>> BalusC for the amazingly quick turnaround on that. I did just enough of
>> SPEC-1107 to get to the point where I could write the VDLDoc for
>> f:socket, which you see at [2].
>>
>> [2]
>> https://maven.java.net/service/local/repositories/snapshots/archive/org/glassfish/javax.faces/2.3.0-m04-SNAPSHOT/javax.faces-2.3.0-m04-20150812.142218-46-documentation.jar/!/vdldoc/f/socket.html
>>
>> [3] http://www.primefaces.org/docs/vdl/4.0/primefaces-p/socket.html
>>
>>
>