Hi,
It has already been thought about, it can be combined with h:commandScript,
also new in JSF 2.3.
<f:websocket ... onmessage="someCommandScript" />
<h:commandScript name="someCommandScript" action="#{bean.pushed}"
render="foo" />
The message will transparently be available as request parameters in
associated bean.
Cheers, B
On Fri, Sep 23, 2016 at 9:22 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> Hi
>
> I have been thinking about the way how f:websocket / PushContext works,
> just trying to see what's missing or another way to see this feature, to
> see if we can make it better.
>
> Even if f:websocket behavior is well understood and very flexible the way
> it is, what bothers me about it is this feature is too javascript specific.
> What I mean is you always need to write a javascript block to handle the
> incoming processing.
>
> But sometimes what you really want is update a part or just an specific
> component in the view. In other words, sometimes the web socket is only
> used as way to notify the view that something has changed on the server and
> the view needs to be updated somehow.
>
> In other words, sometimes the user doesn't want to override onmessage and
> instead just say update component xxx or yyy.
>
> For example, imagine the following syntax:
>
> <f:websocket channel="ping">
> <f:ajax event="update" render="myInfoBox"/>
> </f:websocket>
>
> On the server the update is triggered using this:
>
> @Inject
> @Push(channel="ping")
> private PushContext push;
>
> ....
>
> push.send("update");
>
> Now, f:websocket looks more like a component that implements
> ClientBehaviorHolder than a tag, and the "default" onmessage is a method
> that takes the message and if the event match the message it triggers the
> related f:ajax script.
>
> In html markup, f:websocket should create a html tag with the associated
> custom events.
>
> What do you think guys about it? does it work? is it useful? is it worth?
>
> regards,
>
> Leonardo Uribe
>
>
>