From: Neil Griffin <neil.griffin_at_portletfaces.org>
Date: Tue, 25 Oct 2016 19:19:32 -0400

@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