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

              blocks

              Improvement - An improvement or enhancement to an existing feature or task. ICE-5868 MyFaces 2 compatibility

              • Major - Major loss of function.
              • Closed
              depends on

              Improvement - An improvement or enhancement to an existing feature or task. ICE-7091 MyFaces 2 causes full forms to be updated after first Ajax request

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                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.
                Hide
                Permalink
                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
                Hide
                Permalink
                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.
                Hide
                Permalink
                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?
                Hide
                Permalink
                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
                Hide
                Permalink
                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

                  People

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

                    Dates

                    • Created:
                      Updated:
                      Resolved: