MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-2216

The partialSubmit does not work with JSF 2 RI

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-core
    • Fix Version/s: 2.1.0-core
    • Component/s: Components
    • Labels:
      None
    • Environment:
      Mojarra 2.1.6 (SNAPSHOT 20111206)
      Glassfish 3.1.1
      Trinidad 2.0.0

      Description

      Trinidad's partialSubmit does not work because the source parameter passed in the jsf.ajax.request call is null. See XMLRequest.js on the line 358. The source is part of the payload but is not assigned to the source parameter itself. It causes the RI implementation of jsf.ajax.request throws an error because of this code in it:

      if (typeof source === 'undefined' || source === null)

      { throw new Error("jsf.ajax.request: source not set"); }

      1. TRINIDAD-2216.patch
        2 kB
        Max Starets
      2. TRINIDAD-2216-2259-2302.patch
        4 kB
        Robert Schoch

        Issue Links

          Activity

          Hide
          Tobias added a comment -

          Hello,
          looks like I have the same problem.
          Environment: Tomcat 7.0.27, Servlet 2.5, com.sun.faces:jsf-impl:2.1.7, org.apache.myfaces.trinidad:trinidad-impl:2.0.1, Facelets, (tested on firefox and chrome)

          <tr:commandButton id="save" partialSubmit="true" text="save" actionListener="#

          {Bean.save}

          " />

          I also think that this is causing https://issues.apache.org/jira/browse/TRINIDAD-2238

          Show
          Tobias added a comment - Hello, looks like I have the same problem. Environment: Tomcat 7.0.27, Servlet 2.5, com.sun.faces:jsf-impl:2.1.7, org.apache.myfaces.trinidad:trinidad-impl:2.0.1, Facelets, (tested on firefox and chrome) <tr:commandButton id="save" partialSubmit="true" text="save" actionListener="# {Bean.save} " /> I also think that this is causing https://issues.apache.org/jira/browse/TRINIDAD-2238
          Hide
          Giorgos Chasapis added a comment -

          I could very easy reproduce the problem. Unfortunately it was reported on February and still hasn't even been assigned to anyone.

          Show
          Giorgos Chasapis added a comment - I could very easy reproduce the problem. Unfortunately it was reported on February and still hasn't even been assigned to anyone.
          Hide
          Robert Schoch added a comment - - edited

          The patch, which I have attached seems to be the solution of the problem!

          EDIT: removed the patch, because it works only for
          https://issues.apache.org/jira/browse/TRINIDAD-2238
          The patch is available there.

          Show
          Robert Schoch added a comment - - edited The patch, which I have attached seems to be the solution of the problem! EDIT: removed the patch, because it works only for https://issues.apache.org/jira/browse/TRINIDAD-2238 The patch is available there.
          Hide
          Robert Schoch added a comment - - edited

          The renderer creates for a tr:commandButton without explicit id attribute this:

          <button class="af_commandButton" onclick="TrPage._autoSubmit('TestForm','j_idt1',event,1);return false;" type="button">PPR Test</button>

          You can see, that the onclick handler contains an TrPage._autoSubmit() call with a autogenerated source id as argument. This is the reason why the source is part of the payload.

          But the <button> tag has no rended id attribute, so that it can never be found by the script, which searches the element in the DOM tree. This causes a null to be passed as source parameter in the jsf.ajax.request call and finally ends as error like "jsf.ajax.request: source not set" in Mojarra.

          EDIT: same problem here:

          https://issues.apache.org/jira/browse/TRINIDAD-2259
          https://issues.apache.org/jira/browse/TRINIDAD-2302

          Show
          Robert Schoch added a comment - - edited The renderer creates for a tr:commandButton without explicit id attribute this: <button class="af_commandButton" onclick="TrPage._autoSubmit('TestForm','j_idt1',event,1);return false;" type="button">PPR Test</button> You can see, that the onclick handler contains an TrPage._autoSubmit() call with a autogenerated source id as argument. This is the reason why the source is part of the payload. But the <button> tag has no rended id attribute, so that it can never be found by the script, which searches the element in the DOM tree. This causes a null to be passed as source parameter in the jsf.ajax.request call and finally ends as error like "jsf.ajax.request: source not set" in Mojarra. EDIT: same problem here: https://issues.apache.org/jira/browse/TRINIDAD-2259 https://issues.apache.org/jira/browse/TRINIDAD-2302
          Hide
          Robert Schoch added a comment - - edited

          This is a code snipped from trinidad-2.0.1-api, class org.apache.myfaces.trinidad.render.CoreRenderer.java:

          ...
          /**

          • Returns true if the component should render an ID. Components
          • that deliver events should always return "true".
            */
            // TODO Is this a bottleneck? If so, optimize!
            protected boolean shouldRenderId(
            ...

          But I can not find any code that does this really what's in the comment.
          Not even in the subclasses.

          Patch proposal follows...

          EDIT: Patch is now available, see Attachment TRINIDAD-2216-2259-2302.patch

          Show
          Robert Schoch added a comment - - edited This is a code snipped from trinidad-2.0.1-api, class org.apache.myfaces.trinidad.render.CoreRenderer.java: ... /** Returns true if the component should render an ID. Components that deliver events should always return "true". */ // TODO Is this a bottleneck? If so, optimize! protected boolean shouldRenderId( ... But I can not find any code that does this really what's in the comment. Not even in the subclasses. Patch proposal follows... EDIT: Patch is now available, see Attachment TRINIDAD-2216 -2259-2302.patch
          Hide
          Scott O'Bryan added a comment -

          Guys, before we look at committing this, have you tried the trinidad trunk to see if this is still an issue. Technically speaking, Trinidad 2.1, not Trinidad 2.0 should be used with JSF 2.1

          Show
          Scott O'Bryan added a comment - Guys, before we look at committing this, have you tried the trinidad trunk to see if this is still an issue. Technically speaking, Trinidad 2.1, not Trinidad 2.0 should be used with JSF 2.1
          Hide
          Robert Schoch added a comment -

          Have tried the Trinidad 2.1.0 Snapshot: trinidad-api-2.1.0-20121023.010853-35.jar & trinidad-impl-2.1.0-20121023.011048-35.jar with Mojarra 2.1.13 on Tomcat 7.0.32, but there is currently another problem with the xhtml files: All Action Methods and Event Listeners are processed now as Value Expression and not as Method Expression.

          This causes the following Error:

          javax.el.ELException: /launch.xhtml: Property 'dialogLaunchListener' not found on type de.ospkdd.sample.DialogController
          at com.sun.faces.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:94)
          at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
          at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
          at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
          at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:424)
          at org.apache.myfaces.trinidad.view.ViewDeclarationLanguageWrapper.renderView(ViewDeclarationLanguageWrapper.java:101)
          at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
          at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
          ...

          No such ELException's with an older Snapshot! Have tried the api/impl jar's from trinidad-demo-2.1.0-20120531.161633-2.

          But the original problem with the not rendered id's and the "jsf.ajax.request: source not set" still exist.

          Show
          Robert Schoch added a comment - Have tried the Trinidad 2.1.0 Snapshot: trinidad-api-2.1.0-20121023.010853-35.jar & trinidad-impl-2.1.0-20121023.011048-35.jar with Mojarra 2.1.13 on Tomcat 7.0.32, but there is currently another problem with the xhtml files: All Action Methods and Event Listeners are processed now as Value Expression and not as Method Expression. This causes the following Error: javax.el.ELException: /launch.xhtml: Property 'dialogLaunchListener' not found on type de.ospkdd.sample.DialogController at com.sun.faces.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:94) at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782) at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:424) at org.apache.myfaces.trinidad.view.ViewDeclarationLanguageWrapper.renderView(ViewDeclarationLanguageWrapper.java:101) at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288) ... No such ELException's with an older Snapshot! Have tried the api/impl jar's from trinidad-demo-2.1.0-20120531.161633-2. But the original problem with the not rendered id's and the "jsf.ajax.request: source not set" still exist.
          Hide
          Robert Schoch added a comment -

          None of the Trinidad Committers have the time to check this and integrate the patch?

          Show
          Robert Schoch added a comment - None of the Trinidad Committers have the time to check this and integrate the patch?
          Hide
          Max Starets added a comment -

          Rather than force rendering Id for components, I think it is a better idea to detect in Javascript that we need to set the Id that is lready being passed to the event handler

          Show
          Max Starets added a comment - Rather than force rendering Id for components, I think it is a better idea to detect in Javascript that we need to set the Id that is lready being passed to the event handler
          Hide
          Pavel Zorin added a comment -

          Still cannot trigger tr:showDetail without explicitly defined id and without applied TRINIDAD-2216-2259-2302.patch (with if(COMPONENT_FAMILIES_SHOULD_RENDER_ID.contains(family)) check)

          Show
          Pavel Zorin added a comment - Still cannot trigger tr:showDetail without explicitly defined id and without applied TRINIDAD-2216 -2259-2302.patch (with if(COMPONENT_FAMILIES_SHOULD_RENDER_ID.contains(family)) check)
          Hide
          Scott O'Bryan added a comment -

          Looks like this was committed but not closed.

          r1438160 | mstarets | 2013-01-24 20:22:37 +0000 | 1 line
          Changed paths:
          M /myfaces/trinidad/trunk/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/xhr/XMLRequest.js

          TRINIDAD-2216 - The partialSubmit does not work with JSF 2 RI

          Show
          Scott O'Bryan added a comment - Looks like this was committed but not closed. r1438160 | mstarets | 2013-01-24 20:22:37 +0000 | 1 line Changed paths: M /myfaces/trinidad/trunk/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/xhr/XMLRequest.js TRINIDAD-2216 - The partialSubmit does not work with JSF 2 RI

            People

            • Assignee:
              Scott O'Bryan
              Reporter:
              Tomas Havelka
            • Votes:
              5 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development