+1 for adding <f:ajax> support to <f:websocket>. I believe PrimeFaces does
this with <p:socket>, and it's certainly more intuitive than hooking it up
to <f:commandScript>.
___
Kito D. Mann | @kito99 | Author, JSF in Action
Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay training and
consulting
Virtua, Inc. | virtua.tech
JSFCentral.com | @jsfcentral | knowesis.io
<
http://knowesis.io/web/webcomponents> - fresh Web Components info
+1 203-998-0403
* Listen to the Enterprise Java Newscast: *http://
<
http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<
http://ww.enterprisejavanews.com>*
On Sun, Sep 25, 2016 at 11:55 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> 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
>>>>
>>>>
>>>>
>>>
>>
>