jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Re: Re: Re: improvements to f:websocket and PushContext

From: Bauke Scholtz <balusc_at_gmail.com>
Date: Thu, 27 Oct 2016 10:15:30 +0200

Hi,

Usage of <h:commandScript name> is essentially exactly the same as <f:ajax
onevent>. Its vdldoc however merely states "The name of the JavaScript
function that will handle UI events". Should this also be improved?

Cheers, B

On Wed, Oct 26, 2016 at 3:47 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:

> Hi
>
> NG>> Therefore I propose that the responsibility of namespacing the
> NG>> h:commandScript "name" attribute be placed on the JSF portlet
> developer,
> NG>> and not on the FacesBridge or Faces Runtime.
>
> Sounds good to me. Maybe a warning in the tlddoc or javadoc of
> h:commandScript
> "name" would be helpful, to avoid later reports on the issue tracker.
> Something like "... it is resposibility of the developer to choose a
> naming
> convention if the component could be rendered many times on the same view
> ..."
>
> The important thing is one way or another, the way how to use "name" must
> be clear to developers.
>
> regards,
>
> Leonardo Uribe
>
>
> 2016-10-25 18:28 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
>
>> 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/6f0407c2d5d877
>> d20025a7f249597cfce06c924d
>> >>
>> >> 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
>> >
>>
>>
>