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