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