Hi
I have checked the documentation and the code inside MyFaces and I have
noticed that option.params is bound to ClientBehaviorContext.Parameter, but
it is not related to f:param.
The code reveals there are no instances of ClientBehaviorContext.Parameter
created in any place. Nested f:ajax and f:param doesn't work.
I suppose the author intention is affect the underlying client behavior,
but that's something different to the functionality of f:param, which is
provide a piece of information to the component to be decoded later.
It is true that f:ajax doesn't use that part, but from the model
perspective this is something inherited from client behavior abstract
classes.
Could it be a misunderstanding here? difficult to say. Ed is the only one
who knows it, but I suppose everything works as expected, but maybe there
is a case we have not specified related to f:param inside a client
behavior.
regards,
Leonardo Uribe
2016-03-21 4:53 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>