Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.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:
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 -
Deryk Sinotte
made changes -
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 ] |
Deryk Sinotte
made changes -
Salesforce Case | [] | |
Fix Version/s | 2.1 [ 10241 ] |
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] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #26839 | Mon Dec 12 16:05:32 MST 2011 | yip.ng | |
Files Changed | ||||
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 ] |
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 | |
Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/DOMRenderKit.java
DEL /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/html_basic/MessagesRenderer.java DEL /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/html_basic/MessageRenderer.java |
Ken Fyten
made changes -
Fix Version/s | 3.0.RC2 [ 10313 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
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.