ICEfaces
  1. ICEfaces
  2. ICE-6621

Message(s) rendering not overridable by application

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 2.0.0
          • Fix Version/s: 2.0.1
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            ICEfaces 2. Details specific to Mojarra

            Description

            We've implemented our own Message Renderer and Messages Renderer, so that the output will always be wrapped in a div, to better work with our dom differencing. As part of the MyFaces 2 integration in ICE-5868 we switched from using the faces-context.xml to override the renderers to doing it programmatically, since our renderers override the Mojarra ones, and we can't use them with MyFaces. This has the side-effect of thwarting applications from overriding the renderers themselves.

            The quickest fix would be to change the renderkit code that checks to see if we should override the renderers to do an exact class name check for the Mojarra renderers, so that we don't stomp on 3rd party renderers.
            1. Java Source File
              CustomMessagesRenderer.java
              11 kB
              yip.ng
            1. screenshot-01.png
              107 kB
            2. screenshot-02.png
              116 kB
            3. screenshot-03.png
              104 kB

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              yip.ng added a comment - - edited

              Order of registering renderers is: @FacesRenderer(), JSF, faces-config.xml. See screenshot 1.

              Therefore, declaration in @FacesRenderer() will be replaced by JSF declaration if renderer type id is the same. Therefore, must use faces-config.xml.

              Or, we can make (component family id + renderer type id) unique. However, because they are set in the component class (javax.faces.component.html.HtmlMessages), this is impossible without overriding the component class.

              Show
              yip.ng added a comment - - edited Order of registering renderers is: @FacesRenderer(), JSF, faces-config.xml. See screenshot 1. Therefore, declaration in @FacesRenderer() will be replaced by JSF declaration if renderer type id is the same. Therefore, must use faces-config.xml. Or, we can make (component family id + renderer type id) unique. However, because they are set in the component class (javax.faces.component.html.HtmlMessages), this is impossible without overriding the component class.
              Hide
              Permalink
              yip.ng added a comment -

              Delegate render kit in DOMRenderKit is always com.sun.faces.renderkit.RenderKitImpl.

              Show
              yip.ng added a comment - Delegate render kit in DOMRenderKit is always com.sun.faces.renderkit.RenderKitImpl.
              Hide
              Permalink
              Mark Collette added a comment -

              Probably not when with MyFaces 2 though, right?

              Show
              Mark Collette added a comment - Probably not when with MyFaces 2 though, right?
              Hide
              Permalink
              yip.ng added a comment -

              With MyFaces, delegate is org.apache.myfaces.renderkit.html.HtmlRenderKitImpl.

              Show
              yip.ng added a comment - With MyFaces, delegate is org.apache.myfaces.renderkit.html.HtmlRenderKitImpl.
              Hide
              Permalink
              yip.ng added a comment -

              With MyFaces, order of registering renderers is: JSF, faces-config.xml, @FacesRenderer(). See screenshot 3.

              Therefore, @FacesRenderer() should work.

              Show
              yip.ng added a comment - With MyFaces, order of registering renderers is: JSF, faces-config.xml, @FacesRenderer(). See screenshot 3. Therefore, @FacesRenderer() should work.
              Hide
              Permalink
              yip.ng added a comment - - edited

              Changed in DOMRenderKit from checking component family and renderer type ids ("javax.faces.Message") to checking renderer class name ("com.sun.faces.renderkit.html_basic.MessageRenderer".), i.e., only override with our renderer class ("org.icefaces.impl.renderkit.html_basic.MessageRenderer") when registered rendderer class is Mojarra class.

              Side effect: with MyFaces, the class name is "org.apache.myfaces.renderkit.html.HtmlMessageRenderer", so our override renderer class can't take over anymore.

              Same with MessagesRenderer.

              User-registered renderer works now provided user registers the renderer in the proper order mentioned above. See screenshot 2.

              Revision: 24081

              Modified : /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/DOMRenderKit.java

              Show
              yip.ng added a comment - - edited Changed in DOMRenderKit from checking component family and renderer type ids ("javax.faces.Message") to checking renderer class name ("com.sun.faces.renderkit.html_basic.MessageRenderer".), i.e., only override with our renderer class ("org.icefaces.impl.renderkit.html_basic.MessageRenderer") when registered rendderer class is Mojarra class. Side effect: with MyFaces, the class name is "org.apache.myfaces.renderkit.html.HtmlMessageRenderer", so our override renderer class can't take over anymore. Same with MessagesRenderer. User-registered renderer works now provided user registers the renderer in the proper order mentioned above. See screenshot 2. Revision: 24081 Modified : /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/DOMRenderKit.java

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: