ICEfaces
  1. ICEfaces
  2. ICE-6622

Message(s) rendering for MyFaces

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 3.0.RC2, 3.0
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 2 + MyFaces 2
    • Assignee Priority:
      P2
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      For h:message, provide an id for the tag - e.g. <h:message for="myComponent" id="myComponentMsg'/>. Providing an id forces h:message to render an initial span that acts as an updateable container. This technique does not work for h:messages.
      Show
      For h:message, provide an id for the tag - e.g. <h:message for="myComponent" id="myComponentMsg'/>. Providing an id forces h:message to render an initial span that acts as an updateable container. This technique does not work for h:messages.

      Description

      When using ICEfaces with Mojarra, we override the message and messages rendering to wrap the output in a div, so that when we transition between having zero messages and any number of messages, or back, then we won't get dom differencing propagation. We accomplish by extending the Mojarra renderers, and adding the div behaviour. This doesn't work in a MyFaces environment. If MyFaces doesn't adopt our suggestion of adding the div themselves to their own renderers, then we should find a way of providing this functionality with that JSF environment.

        Issue Links

          Activity

          Mark Collette created issue -
          Mark Collette made changes -
          Field Original Value New Value
          Link This issue blocks ICE-5868 [ ICE-5868 ]
          Deryk Sinotte made changes -
          Link This issue depends on ICE-7091 [ ICE-7091 ]
          Hide
          Deryk Sinotte added a comment -

          There are a couple of things to note here:

          1) Currently, the way that the ViewState is updated when running with MyFaces leads to unnecessarily large updates - particularly with the initial Ajax request. I've spun off a separate JIRA to cover this case: ICE-7091. The reason to referring to it here is that the updates caused by the h:message(s) renders are difficult to diagnose due to the problem with the large initial form update.

          2) Both the h:message and h:messages tags will not render anything if an "id" attribute is not provided. When a request triggers a message, the resulting change to the DOM will trigger a DOM diff. Without a uniquely identified "container" to replace, the resulting DOM diff will target the form or even the body as the updateable region resulting in larger than necessary updates.

          3) By adding an "id" attribute:

          h:message will render a <span id=... />
          h:messages will render a <div id=... />

          A subsequent request that contains a message to display will work properly for h:message because the <span> is updated with a <span>. For h:messages, simply adding an id does not help as the <div> is replaced by a <ul> which leads to a search up the DOM to find a suitable parent to replace. So adding an "id" to an h:message is a suitable workaround but not for h:messages.

          Show
          Deryk Sinotte added a comment - There are a couple of things to note here: 1) Currently, the way that the ViewState is updated when running with MyFaces leads to unnecessarily large updates - particularly with the initial Ajax request. I've spun off a separate JIRA to cover this case: ICE-7091 . The reason to referring to it here is that the updates caused by the h:message(s) renders are difficult to diagnose due to the problem with the large initial form update. 2) Both the h:message and h:messages tags will not render anything if an "id" attribute is not provided. When a request triggers a message, the resulting change to the DOM will trigger a DOM diff. Without a uniquely identified "container" to replace, the resulting DOM diff will target the form or even the body as the updateable region resulting in larger than necessary updates. 3) By adding an "id" attribute: h:message will render a <span id=... /> h:messages will render a <div id=... /> A subsequent request that contains a message to display will work properly for h:message because the <span> is updated with a <span>. For h:messages, simply adding an id does not help as the <div> is replaced by a <ul> which leads to a search up the DOM to find a suitable parent to replace. So adding an "id" to an h:message is a suitable workaround but not for h:messages.
          Deryk Sinotte made changes -
          Workaround Description For h:message, provide an id for the tag - e.g. <h:message for="myComponent" id="myComponentMsg'/>. Providing an id forces h:message to render an initial span that acts as an updateable container. This technique does not work for h:messages.
          Workaround Exists [Yes]
          Salesforce Case []
          Assignee Priority P2
          Assignee Deryk Sinotte [ deryk.sinotte ]
          Hide
          Deryk Sinotte added a comment -

          We've opened a ticket with MyFaces and asked them to modify the renderers to provide a consistent parent container with an id so that the messages can be reliably and efficiently updated via Ajax:

          https://issues.apache.org/jira/browse/MYFACES-3272

          Show
          Deryk Sinotte added a comment - We've opened a ticket with MyFaces and asked them to modify the renderers to provide a consistent parent container with an id so that the messages can be reliably and efficiently updated via Ajax: https://issues.apache.org/jira/browse/MYFACES-3272
          Deryk Sinotte made changes -
          Salesforce Case []
          Fix Version/s 2.1 [ 10241 ]
          Hide
          Ken Fyten added a comment -

          Basically need a similar custom message and message(s) component renderers that we already use for Mojarra components, but for MyFaces.

          Show
          Ken Fyten added a comment - Basically need a similar custom message and message(s) component renderers that we already use for Mojarra components, but for MyFaces.
          Ken Fyten made changes -
          Salesforce Case []
          Assignee Deryk Sinotte [ deryk.sinotte ] yip.ng [ yip.ng ]
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s EE-3.0.0.GA [ 10262 ]
          Fix Version/s 3.0 [ 10241 ]
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 3.0 [ 10241 ]
          Fix Version/s EE-3.0.0.GA [ 10262 ]
          Affects [Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration]
          Hide
          yip.ng added a comment -

          Ready to make changes. Changes are NOT similar to those in Mojarra. Classes to change:

          org.apache.myfaces.renderkit.html.HtmlMessageRenderer
          org.apache.myfaces.shared.renderkit.html.HtmlMessageRendererBase
          org.apache.myfaces.renderkit.html.HtmlMessagesRenderer
          org.apache.myfaces.shared.renderkit.html.HtmlMessagesRendererBase

          (Mojarra doesn't have the base renderer classes.)
          (org.icefaces.impl.renderkit.DOMRenderKit needs to be changed as well.)

          1. Where in the core should these classes be copied to? Same as modified Mojarra classes? Change class names?
          2. They reference other MyFaces classes. Would it break the build?
          3. Code studied is 2.1.4. Our jars are 2.1.3. Get the 2.1.3 source code to change? Or will 2.1.3 jars be replaced soon?

          Show
          yip.ng added a comment - Ready to make changes. Changes are NOT similar to those in Mojarra. Classes to change: org.apache.myfaces.renderkit.html.HtmlMessageRenderer org.apache.myfaces.shared.renderkit.html.HtmlMessageRendererBase org.apache.myfaces.renderkit.html.HtmlMessagesRenderer org.apache.myfaces.shared.renderkit.html.HtmlMessagesRendererBase (Mojarra doesn't have the base renderer classes.) (org.icefaces.impl.renderkit.DOMRenderKit needs to be changed as well.) 1. Where in the core should these classes be copied to? Same as modified Mojarra classes? Change class names? 2. They reference other MyFaces classes. Would it break the build? 3. Code studied is 2.1.4. Our jars are 2.1.3. Get the 2.1.3 source code to change? Or will 2.1.3 jars be replaced soon?
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #26839 Mon Dec 12 16:05:32 MST 2011 yip.ng ICE-6622: Message(s) rendering for MyFaces.
          Files Changed
          Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/DOMRenderKit.java
          yip.ng made changes -
          Attachment screenshot-1.png [ 13870 ]
          yip.ng made changes -
          Attachment screenshot-1.png [ 13870 ]
          yip.ng made changes -
          Attachment screenshot-1.png [ 13871 ]
          Hide
          yip.ng added a comment - - edited

          Deryk suggested using renderer wrapper as per org.icefaces.impl.renderkit.DOMRenderKit.FormBoost. No need to touch original source code as we did with Mojarra.

          Done. See screenshot-1.png.

          Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\DOMRenderKit.java
          Completed: At revision: 26839

          Show
          yip.ng added a comment - - edited Deryk suggested using renderer wrapper as per org.icefaces.impl.renderkit.DOMRenderKit.FormBoost. No need to touch original source code as we did with Mojarra. Done. See screenshot-1.png. Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\DOMRenderKit.java Completed: At revision: 26839
          yip.ng made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #26848 Tue Dec 13 09:44:21 MST 2011 yip.ng ICE-6622: Message(s) rendering for MyFaces.
          Files Changed
          Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/DOMRenderKit.java
          Commit graph DEL /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/html_basic/MessagesRenderer.java
          Commit graph DEL /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/html_basic/MessageRenderer.java
          Hide
          yip.ng added a comment -

          Removed customized Mojarra classes.

          Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\DOMRenderKit.java
          Deleting: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\html_basic\MessageRenderer.java
          Deleting: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\html_basic\MessagesRenderer.java
          Completed: At revision: 26848

          Show
          yip.ng added a comment - Removed customized Mojarra classes. Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\DOMRenderKit.java Deleting: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\html_basic\MessageRenderer.java Deleting: C:\svn\ossrepo\icefaces3\trunk\icefaces\core\src\main\java\org\icefaces\impl\renderkit\html_basic\MessagesRenderer.java Completed: At revision: 26848
          Ken Fyten made changes -
          Fix Version/s 3.0.RC2 [ 10313 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              yip.ng
              Reporter:
              Mark Collette
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: