Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.1
    • Fix Version/s: None
    • Component/s: Ajax/JavaScript
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      874
    • Status Whiteboard:
      Hide

      size_small importance_medium

      Show
      size_small importance_medium

      Description

      On 8/3/10 10:45 AM, Werner Punz 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:
      > o If the keyword @none is present, do not create and send the post
      data argument javax.faces.partial.execute.
      > o If the keyword @all is present, create the post data argument with
      the name javax.faces.partial.execute and the value @all.
      > o 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 string of 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

      On 8/4/10 3:31 AM, Martin Marinschek 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/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

        Activity

        Hide
        rogerk added a comment -

        Evaluate

        Show
        rogerk added a comment - Evaluate
        Hide
        rogerk added a comment -

        For now re-target for 2.2.
        If time permits may revisit for 2.1.

        Show
        rogerk added a comment - For now re-target for 2.2. If time permits may revisit for 2.1.
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        werpu12 added a comment -

        Ok MyFaces has in the meanwhile cloned mojarras behavior in this regard. So we probably can nail down the mojarra status quo into the spec.

        Show
        werpu12 added a comment - Ok MyFaces has in the meanwhile cloned mojarras behavior in this regard. So we probably can nail down the mojarra status quo into the spec.
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          People

          • Assignee:
            Unassigned
            Reporter:
            rogerk
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: