[jsr372-experts] Re: jsf.ajax.request() options.params is never considered in Mojarra

From: Bauke Scholtz <balusc_at_gmail.com>
Date: Mon, 21 Mar 2016 10:43:27 +0100

Also on MyFaces: https://issues.apache.org/jira/browse/MYFACES-4040

Cheers, Bauke

On Mon, Mar 21, 2016 at 10:36 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:

> Nonetheless, I created an issue on this:
> https://java.net/jira/browse/JAVASERVERFACES-4115
> I will consider the both implementations exposing the similar issue as
> "coincidence". If all unit tests run successfully after fixing this in
> master, I'll push it forward.
> Cheers, Bauke
> On Sat, Mar 19, 2016 at 3:34 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>> Hi,
>> The current implementations will generally work just fine, but if there's
>> a <f:param> with one of the names "execute", "render", "onevent", etc, such
>> as <f:param name="execute" value="not a client ID">, then things will fail.
>> To be sure, I have just tested both Mojarra 2.2.13 and MyFaces 2.2.9 on
>> this, both indeed expose problems on this. Given below test snippet,
>> <h:form>
>> <h:inputText id="foo" value="#{bean.input}" />
>> <h:commandLink value="test">
>> <f:ajax execute="foo" />
>> <f:param name="execute" value="not a client ID" />
>> </h:commandLink>
>> </h:form>
>> In Mojarra, the <f:ajax execute> works fine, but <f:param name="execute">
>> disappears in request parameter map.
>> In MyFaces, the <f:ajax execute> will be overridden with <f:param
>> name="execute"> and thus "someClientId" won't be executed, and the <f:param
>> name="execute"> also disappears in request parameter map.
>> Cheers, B
>> On Sat, Mar 19, 2016 at 3:01 PM, Josh Juneau <juneau001_at_gmail.com> wrote:
>>> Thanks Bauke and everyone else involved in getting Milestone 5 out the
>>> door!
>>> This particular issue sounds to me like an implementation that was
>>> either decided against after the code was already completed...or conversely
>>> something that was planned but never completed. Thanks for uncovering. It
>>> certainly seems like an area that needs to be cleaned up.
>>> Josh Juneau
>>> juneau001_at_gmail.com
>>> http://jj-blogger.blogspot.com
>>> https://www.apress.com/index.php/author/author/view/id/1866
>>> On Fri, Mar 18, 2016 at 12:07 PM, Bauke Scholtz <balusc_at_gmail.com>
>>> wrote:
>>>> Hi,
>>>> While working on
>>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-618 (a new
>>>> h:commandScript), I noticed that options.params as documented in
>>>> https://javaserverfaces.java.net/nonav/docs/2.2/jsdocs/symbols/jsf.ajax.html#.request
>>>> is never actually used in Mojarra's javax.faces:jsf.js. Instead the entire
>>>> options object itself is sent as params (after explicitly removing the
>>>> execute/render/onerror/onevent/delay properties).
>>>> This looks like a bug in the implementation. Moreover, the mojarra.ab
>>>> function (which is used by a.o. <h:commandLink><f:ajax>) is implemented in
>>>> such way that it simply merges the params into options object instead of
>>>> making it a "params" property of the options object.
>>>> I checked MyFaces on this (not tested) but based on the Impl.js source
>>>> code it seems to nowhere use options.params property too. Due to both JSF
>>>> implementations exposing the same issue, I'm not sure anymore if I misread
>>>> the JS doc.
>>>> Ed/Leonardo, was this intentional or is this indeed a bug? If
>>>> intentional then a spec change is required to alter the JS doc. If not then
>>>> a new issue needs to be created to align out.
>>>> Cheers, Bauke