Sorry, typo: I should have written "responsibility of namespacing the h:commandScript ..." and not h:commandButton.
> On Oct 25, 2016, at 7:19 PM, Neil Griffin <neil.griffin_at_portletfaces.org> wrote:
>
> @Bauke, @Leonardo: Thank you very much for considering the portlet case.
>
> Portlet developers are aware that they need to namespace JavaScript function names.
>
> I recently tried the following example with Pluto 3.0 + Mojarra 2.3 and it worked fine:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ui:composition xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://xmlns.jcp.org/jsf/html"
> xmlns:portlet="http://xmlns.jcp.org/portlet_3_0"
> xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
>
> <portlet:namespace var="portletNamespace" />
> <h:form>
> <h:commandScript name="#{portletNamespace}myJsClientFunction" action="#{myBean.myJavaServerMethod('bar')}" render=":output" />
> </h:form>
> <button onclick="#{portletNamespace}myJsClientFunction()" />
> <h:outputText id="output" value="#{myBean.output}" />
>
> </ui:composition>
>
> Therefore I propose that the responsibility of namespacing the h:commandButton "name" attribute be placed on the JSF portlet developer, and not on the FacesBridge or Faces Runtime.
>
>
> Best Regards,
>
> Neil
>
>> On Oct 8, 2016, at 4:02 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>
>> 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
>