Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: EE-2.0.0.Alpha1
-
Fix Version/s: EE-2.0.0
-
Component/s: Facelet Components
-
Labels:None
-
Environment:jsf 2.1
Description
The Rich Data component is seems to work as advertised if everything is done very slowly and the Lifecycle is allowed to finish between requests. The component needs few seconds to render in the render response phase which seems to kill the bridge code if the demo/component is quick clicked on.
The component should be looked at to see if anything can be done to optimize the render time of the component. The behaviour seem about the same in 1.8.2 .
The component should be looked at to see if anything can be done to optimize the render time of the component. The behaviour seem about the same in 1.8.2 .
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Suggested changes to blanket use of singleSubmit noted above have been implemented. This demo is still fairly slow, however. Perhaps if the two tables were put in separate demos that would help? (I'm assuming each one demonstrates some unique from the other in terms of component features or usage that warrants keeping both).
Show
Ken Fyten
added a comment - Suggested changes to blanket use of singleSubmit noted above have been implemented. This demo is still fairly slow, however. Perhaps if the two tables were put in separate demos that would help? (I'm assuming each one demonstrates some unique from the other in terms of component features or usage that warrants keeping both).
- move inline css to external file
- remove popup menu from all columns and put only in last column
- moved hidden columns popup menu into column headers (was in the top pager info panel), to avoid resending menu content in frequent dom diffs for the changing pager info
- trifurcated the rich data grid layout so that the header and footer are not sent in the dom diff when the table data changes (header and footer dom placement changed to separate siblings of data)
performance is now noticeably improved.
Filtering:
- dom updates are much smaller
- filtering much improved as focus is maintained while quickly typing
HTML weight:
-rendered weight is much reduced, will depend on specific table layout and data, but the 1st comp showcase example reduced ~40%
-dom diff sizes are significantly reduced as well
Show
Philip Breau
added a comment -
move inline css to external file
remove popup menu from all columns and put only in last column
moved hidden columns popup menu into column headers (was in the top pager info panel), to avoid resending menu content in frequent dom diffs for the changing pager info
trifurcated the rich data grid layout so that the header and footer are not sent in the dom diff when the table data changes (header and footer dom placement changed to separate siblings of data)
performance is now noticeably improved.
Filtering:
dom updates are much smaller
filtering much improved as focus is maintained while quickly typing
HTML weight:
-rendered weight is much reduced, will depend on specific table layout and data, but the 1st comp showcase example reduced ~40%
-dom diff sizes are significantly reduced as well
It seems that some of the performance issues might be related to the general use of the icecore:singleSubmit tag in the demo application. This is causing any visited input fields, such as data entry fields in editable datable, to do a singleSubmit onblur. This adds numerous extra submits and lifecycles and is not necessary for this demo as it's written to valid, etc. on "save" by clicking the save button.
Changes should be made to the structure of the sample app. to avoid using singleSubmit in a blanket fashion, so that each demo can apply it as required.