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
>