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

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

From: Bauke Scholtz <balusc_at_gmail.com>
Date: Sat, 19 Mar 2016 15:34:08 +0100

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
>>
>
>