Details
New Feature
Major
Description
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
There is another problem has been noticed with the button component. Please see the attached snapshot.
The fix applied makes sure that submitting type elements found among the changed elements are not serialized.
Serialize the element that invokes a full submit (iceSubmit) during a keypress event.
Okay, after review it seems that the approach taken with this prototype is not going to be feasible to pursue further, or possibly include in the product in the future. Work is stopped on this prototype.
As it stands, the prototype has the following:
Key Limitations
- Only works with ice: components (not h:, or other 3rd party or custom components) as it requires specific component changes to function correctly. This is deemed to be a fatal requirement due to the increased complexities involved in supporting the ice components in both "delta submit" and normal submit modes.
- Not configurable. The prototype always uses Delta-submit mode, and cannot be configured not to.
Known Issues:
- QA testing has found that the regression tests associated with JIRA list below are failing with the prototype. These issues will remain unresolved:
Navigation-redirect - not working
Navigation-forward - not working
Navigation-facelet - not working
ICE-751- selectManyCheckBox acting like selectOneRadio
ICE-4011 - calendar AM- PM not working
ICE-3627 - <h:inputText valueChangeListener="#
"
ValueChaneListener not working
ICE-3530 - when alphabet is entered in the autocomplete textbox Number Format exception is thrown
ICE-3051 - navigation not working
ICE-2031 - remove selection not working for last selected item in the selectManyMenu
ICE-1993 - page is not rendered correctly. One full panelGrid is missing on the page
ICE-5118 - Number Format exception when removing a tab, that was added by the user.
Some other exceptions seen in exception log
ICE-3530 - Number Format exception
ICE-3332 - NullPointer Exception
ICE-3028 - RunTime Exception
However, our sample applications (Component Showcase, Auction Monitor, Address demo) all seem to function well.
The prototype may be useful as a demonstration of the kind of bandwidth reduction that can be expected from this type of "delta-submit" feature, but should not be used in anything other than an experimental context.
We are planning on approaching the delta-submit feature from a different angle for ICEfaces 2.0 with a solution that will be completely transparent to the application and component developers, be configurable, etc.
When we started to look at this issue we had two different implementations in mind:
a) The idea for the first implementation is to send only the minimal information such as event and triggering element data. The rest of the parameters that correspond to elements that have not changed since the last submit will be reconstructed on the server-side from the DOM document and then put into ExternalContext's parameter maps before decode phase is ran.
b) The idea for the second implementation is to calculate the parameter difference between submits. The full set of parameters will be reconstructed on the server-side by applying the changes send in submit to the set of parameters stored during the previous submit.
Advantages:
a) Easy to implement. No heavyweight calculations needed. The code on the client side needs to change very little. Reconstructing the full set of parameters on the server is straight forward, just a simple serialization of the form elements.
b) ICEfaces components or third party components will work seamlessly since the parameter diffing will work also with the parameters created by hidden input elements.
Disadvantages:
a) ICEfaces components that use hidden input elements to submit additional parameters will need to be changed. Since the form is not serialized anymore the additional parameters will have to be defined directly in the event callback. Third party components that use hidden fields won't work.
Also, onchange callbacks have to be configured for the form elements. This is necessary in case the element values are changed without an immediate submission. The onchange listeners will record the changed elements and they will be serialized during the next submit.
b) Calculating the parameter difference on the client side is quite expensive, especially for large forms. In order to significantly improve performance we need to implement or find a proper Hashtable implementation. This way lookups will be much faster when calculating what parameters are added or removed.
Also, for sending the parameter differences to the server we have to come up with a protocol for describing parameter addition, removal and update.