Hi,
I just added <f:ajax> support to OmniFaces <o:socket>:
https://github.com/omnifaces/omnifaces/commit/6f0407c2d5d877d20025a7f249597cfce06c924d
The basics work fine and it's indeed much more natural, but I still need to
investigate and if necessary improve the behavior of "connected" and
"rendered" attributes. Once I'm satisfied, I will rework f:websocket based
on this.
I will get back on h:commandScript+portlets later. This is a separate issue
not related to f:websocket.
Cheers, B
On Mon, Oct 3, 2016 at 2:57 PM, Michael Müller <
michael.mueller_at_mueller-bruehl.de> wrote:
> +1
>
> Herzliche Grüße - Best Regards,
>
> Michael Müller
> Brühl, Germany
> blog.mueller-bruehl.de
> it-rezension.de
> @muellermi
>
>
> Read my books
> "Web Development with Java and JSF": https://leanpub.com/jsf
> "Java Lambdas und (parallel) Streams" Deutsche Ausgabe:
> https://leanpub.com/lambdas-de
> "Java Lambdas and (parallel) Streams" English edition:
> https://leanpub.com/lambdas
>
> On 09/26/2016 01:41 PM, Josh Juneau wrote:
>
> +1...I agree. Individuals already understand the way that <f:ajax>
> functions, so it makes sense to use it if possible.
>
> Josh Juneau
> juneau001_at_gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Mon, Sep 26, 2016 at 5:38 AM, Kito Mann <kito.mann_at_virtua.com> wrote:
>
>> +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 <%2B1%20203-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/J
>>> AVASERVERFACES_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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>