[jsr-314-open-mirror] [jsr-314-open] jsf.ajax.request: Bug or expected behavior?
Roger Kitain
roger.kitain at oracle.com
Thu Aug 5 11:09:16 EDT 2010
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
More information about the jsr-314-open-mirror
mailing list