Hi,
h:commandScript is result of
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-613 See also
http://arjan-tijms.omnifaces.org/p/jsf-23.html for others.
I do understand the h:commandScript limitation in portlet case, but in a
portlet app there's also only one JavaScript context.
I have to admit that the f:websocket+f:ajax looks more natural. I will try
creating a POC on this. I only don't like the idea of turning the
f:websocket from TagHandler into UIComponent. It's really kind of view
metadata.
Cheers, B
On Sat, Sep 24, 2016 at 3:53 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> 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-79
> 0.
>
> 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
>>>
>>>
>>>
>>
>