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

[Roger Kitain]

Tracking at:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=874

-roger

On 8/4/10 5:08 AM, Werner Punz wrote:
> Hi,
> I just did some further digging around in the code specially since I 
> am currently doing some optimisation stuff in that area in myfaces. 
> And I came to the conclusion that Mojarras behavior breaks the spec.
>
> The reason. The spec itself leaves it open, but we have an implicit 
> @this parameter which can be set both in execute and in render
> and if this @this parameter is set then the issuing client id has to 
> be set in the list where it is set.
> So the spec clearly states here that @this is a placeholder for the 
> executing element. If is allowed in exec, appending automatically the 
> issuing client id is pointless.
>
> Werner
>
>
> On Wed, Aug 4, 2010 at 9:31 AM, Martin Marinschek 
> <mmarinschek at apache.org <mailto:mmarinschek at apache.org>> wrote:
>
>     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
>     <mailto: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
>
>


-- 
roger.kitain at oracle.com
https://twitter.com/rogerk09
http://www.java.net/blogs/rogerk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100805/89fa46b9/attachment-0002.html