[jsr-314-open-mirror] [jsr-314-open] jsf.ajax.request: Bug or expected behavior?

[Martin Marinschek]

Hi Werner,

I think some clarification would certainly be good there (especially
as the language doesn't really say what client identifiers should be
present, plus once talks about client identifiers, and once about
identifiers only). My POV: for now, Mojarra and MyFaces should behave
the same. The sentence following the one that you highlighted in bold:

"...with the name javax.faces.partial.execute and the value as the
identifier of the element that caused this request..."

indicates to me that the triggering client id should be there.

best regards,

Martin

On 8/3/10, Werner Punz <werner.punz at gmail.com> wrote:
> Hello while doing another round of testing and optimisations I noticed a
> slight difference in the implementations of the request of mojarra and
> myfaces which opened an area where the spec probably is unclear:
>
> Following case:
>
>  <h:panelGroup id="bla">
>
>                        <h:inputText id="inputbla"
> value="#{myBean2.searchTerm}" />
>
>                        <h:commandLink value="Press me for more action"
> action="#{myBean2.doSearch}">
>                            <f:ajax execute="bla" render="content"/>
>                        </h:commandLink>
>                    </h:panelGroup>
>
> now results in following post data:
>
> Mojarra:
>
> form2	form2
> form2:inputbla	
> javax.faces.ViewState	6697453697014869722:-1090088301633916042
> javax.faces.behavior.even...	action
> javax.faces.partial.ajax	true
> javax.faces.partial.event	click
> javax.faces.partial.execu...	form2:j_idt8 form2:bla
> javax.faces.partial.rende...	form2:content
> javax.faces.source	form2:j_idt8
>
>
> in myfaces
> form2:inputbla	
> form2_SUBMIT	1
> javax.faces.ViewState	EmWJgKYkJoTEWDCzpUwZQR3Ek94rGnxK1V6NEZgO6yDgPANeOc1wplJjDYezu2cx9aQ7ZSKNPyGY
> L8P9y5DwH2codFvGPjklD04wuxG4XXTPutNww3pdzIsMkw0=
> javax.faces.behavior.even...	action
> javax.faces.partial.ajax	true
> javax.faces.partial.event	click
> javax.faces.partial.execu...	form2:bla
> javax.faces.partial.rende...	form2:content
> javax.faces.source	form2:j_id1980473354_760ba132
>
>
>
> While most of the differeing data is mostly implementation specific and
> therefor it is not that interesting following is:
>
> javax.faces.partial.execu...	form2:j_idt8 form2:bla
>
>
> compared to
>
> javax.faces.partial.execu...	form2:bla
>
>
> Now the difference is that Mojarra adds the executing element as it seems
> while MyFaces does not.
> The second interesting fact is following definition from the spec:
>
>
>    - Determine additional arguments (if any) from the options argument. If
>    options.execute exists:
>       - If the keyword @none is present, do not create and send the post
>       data argument javax.faces.partial.execute.
>       - If the keyword @all is present, create the post data argument with
>       the name javax.faces.partial.execute and the value @all.
>       - *Otherwise, there are specific identifiers that need to be sent.
>       Create the post data argument with the name
>       javax.faces.partial.execute and the value as a space delimited
> stringof client identifiers.
>       *
>    - If options.execute does not exist, create the post data argument with
>    the name javax.faces.partial.execute and the value as the identifier of
>    the element that caused this request.
>
>
> Which means exactly, that I am not sure which behavior is correct and which
> not. My personal guess is that both implementations are
> correct because the spec clearly leaves it open if the issuing element also
> can be added to the exec list unless no exec list is given at all.
> But that is merely an assumption on my side here.
> Any ideas on this.
>
> Werner
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces