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

[Werner Punz]

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>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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100804/d4848084/attachment-0002.html