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
>
>