Hi
I see, so this is hidden in the spec. Thanks for mention it.
I have to say I can see a problem with this structure, and it is related to
the "name" used on the script.
In JSF each component has it own clientId that is calculated somehow. So
according to the location of the component inside the tree, the clientId is
generated.
The way how clientId works ensures the component can be relocated to
different parts of the tree and it will still work.
The problem with a hardcode name is that you lose this property in the
code. If you are in a portlet case, I can see that if the same component is
used twice on different portlets, the page will crash by a duplicate
definition.
There is a component in tomahawk sandbox that try this and it is called
s:jsCallbackFunction . Remember the component is in sandbox, so in that
sense it is experimental.
* This component creates a function inside an inline <script> tag,
* with a function that can be referenced later using getFunctionName()
method
* inside this component instance or the EL function
#{s:jsCallbackFunctionName(UIComponent)}.
* <p>
* Inside the function, the following code is added:
* </p>
* <code>
* generatedFunctionNameUsingClientIdAndEventName = function (... arguments
...){
* ... jsStartContent ...
* ... clientBehavior scripts ...
* ... jsEndContent ...
* }
* </code>
* <p> This is useful in situations where the context where this script is
* rendered is important, and it is not possible to put the scripts on
static
* javascript files.</p>
What I mean is with an EL function it is possible to generate the function
name based on the clientId of the component and avoid the problem
h:commandScript has.
Let me be clear about this: the way how h:commandScript works right now
creates a conflict for portlet case, and I do not want to create another
one after spend a lot of time trying to solve
JAVASERVERFACES_SPEC_PUBLIC-790.
The way how h:commandScript and f:websocket interact should be more subtle.
If f:websocket is a component with an id, it should be possible to
reference it so you could "declare" a h:commandScript to be called for
f:websocket. So, with one f:websocket it should be possible to call many
h:commandScript functions.
I think we should focus our efforts in create a syntax easy to understand,
that solve the problem of update parts of the view after an event triggered
on the server.
regards,
Leonardo Uribe
2016-09-23 16:01 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
> 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
>>
>>
>>
>