Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces 2, ACE 2.1
-
Assignee Priority:P2
-
Workaround Exists:Yes
-
Workaround Description:Disable the DOM differencing of this component, or of all partial updates.
Description
In org.icefaces.impl.context.DOMPartialRenderCallback.visit(-), around line 458, we find the position of the root of the component, by assuming the component clientId is the id of the root DOM element. We then remove the whole DOM sub-tree corresponding to that component, and setup the DOM cursor so that the component may fully render itself in the vacated space. We then search for the new elements by the clientId, so that we can compare the old sub-tree to the new sub-tree. But if the newly rendered output is not of the whole component, the search for the clientId fails, and we get a NPE.
What needs to be done, is to allow the component to render itself first, adjacent to the old rendering of itself. And then the id of the top-most newly rendered element should be used to find the corresponding old element. If the new top-most element does not have an id, or if it's not found in the old rendering, then the update should just be sent to the browser, without any DOM differencing, and the bridge will deal with it. If the corresponding old element is found, then that old sub-tree may be scraped out, the new sub-tree supplanted in it's place, and the differencing done, so that the optimal change set can be transmitted. In most cases, the top element ids will be the clientId, and it will be the whole component being swapped in, but in special new ACE scenarios, it will be the sub-component regions.
-
Hide
- accordionPanel.war
- 8.97 MB
- Arturo Zambrano
-
- META-INF/MANIFEST.MF 0.1 kB
- ICEfacesPage1.xhtml 0.9 kB
- WEB-INF/.../AccordionPanelBean$1.class 0.2 kB
- WEB-INF/.../AccordionPanelBean$Counter.class 0.7 kB
- WEB-INF/classes/.../AccordionPanelBean.class 4 kB
- WEB-INF/.../AccordionPanelTableBean.class 1 kB
- WEB-INF/faces-config.xml 0.3 kB
- WEB-INF/web.xml 3 kB
- accordionPanelAttribute.xhtml 4 kB
- accordionPanelDataTbl.xhtml 2 kB
- accordionPanelIceTabSet.xhtml 0.0 kB
- accordionPanelPnlTabSet.xhtml 0.0 kB
- accordionPanelPush.xhtml 0.0 kB
- accordionPanelRepeat.xhtml 0.0 kB
- accordionPanelRepeatDataTbl.xhtml 0.0 kB
- accordionPanelTblBttm.xhtml 0.0 kB
- accordionPanelTblTop.xhtml 0.0 kB
- index.jsp 0.0 kB
- readme.txt 0.3 kB
- start.xhtml 1 kB
- WEB-INF/lib/icefaces-ace.jar 4.61 MB
- WEB-INF/lib/icefaces-compat.jar 2.29 MB
- WEB-INF/lib/icefaces.jar 235 kB
- WEB-INF/lib/icepush.jar 293 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/jstl.jar 20 kB
- WEB-INF/lib/javax.faces.jar 2.48 MB
-
Hide
- accordionPanel1.war
- 8.96 MB
- Carmen Cristurean
-
- META-INF/MANIFEST.MF 0.1 kB
- ICEfacesPage1.xhtml 0.9 kB
- WEB-INF/.../AccordionPanelBean$1.class 0.2 kB
- WEB-INF/.../AccordionPanelBean$Counter.class 0.7 kB
- WEB-INF/classes/.../AccordionPanelBean.class 4 kB
- WEB-INF/.../AccordionPanelTableBean.class 1 kB
- WEB-INF/faces-config.xml 0.3 kB
- WEB-INF/web.xml 3 kB
- accordionPanelAttribute.xhtml 4 kB
- accordionPanelDataTbl.xhtml 2 kB
- accordionPanelIceTabSet.xhtml 2 kB
- accordionPanelPnlTabSet.xhtml 2 kB
- accordionPanelPush.xhtml 0.0 kB
- accordionPanelRepeat.xhtml 0.0 kB
- accordionPanelRepeatDataTbl.xhtml 0.0 kB
- accordionPanelTblBttm.xhtml 0.0 kB
- accordionPanelTblTop.xhtml 0.0 kB
- index.jsp 0.0 kB
- readme.txt 0.4 kB
- start.xhtml 1 kB
- WEB-INF/lib/icefaces-ace.jar 4.60 MB
- WEB-INF/lib/icefaces-compat.jar 2.29 MB
- WEB-INF/lib/icefaces.jar 236 kB
- WEB-INF/lib/icepush.jar 293 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/jstl.jar 20 kB
- WEB-INF/lib/javax.faces.jar 2.48 MB
-
- screenshot1.jpg
- 91 kB
-
- screenshot2.jpg
- 78 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
This should now be fixed – the component was not indicating that it required customUpdate, causing the response to corrupt the component. (Inspecting the renderer shows that containing div elements are rendered.)
To verify that this feature is working as expected we should create a new ace:dataTable regression test:
Make test for dataTable row selection that will result in a custom update extension in the response, as well as use the onRowSelectUpdate to specify a region of the page to get a regular jsf update (make sure it changes so dom diff won't suppress), and also make the server side listener use JavascriptRunner to make the response also have an eval section. This way we can test all 3 types of things in the response.
These changes have been tested for the ace accordionPanel component using code Rev# 25567, on tomcat6, and this works well in Firefox 3.6, Firefox 6 and Gchrome 14.
In IE8 browser, the dynamic attribute still doesn't work: after setting dynamic=true, when clicking on one of the closed tabs, the accordionPanel component disappears from the page.
Completed test. Works as expected.
Tested again the ace accordionPanel - dynamic attribute using code rev#25636, and found the issue described above has been fixed.
This has been verified on browsers: IE8, IE7, Firefox 3.6, Gchrome 14, using tomcat6 as server.
Right now we could use the technique from
ICE-6950for TabView, to make it specifically opt out of DOM differencing for partial updates. It seems thatICE-6950was made for 2 scenarios, the JSON response, and these sub-component responses, when maybeICE-6950should only be used for the JSON response issue, and this jiraICE-7032should be for the sub-component issue.