Hi,
Sorry, the link in the first message was wrong, I wasn't working on 618 but
on 613:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-613
Cheers, B
On Mon, Mar 21, 2016 at 10:43 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> 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
>>>>>
>>>>
>>>>
>>>
>>
>