Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.8DR#1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
Description
Similarly to ICE-3454, we want to test the component's saveState and restoreState functionality. But in this case, we want to simply look at every field that's non-static, non-final, and non-transient, give them all unique values, save and restore the components, and see if the fields still retain those values.
Issue Links
- blocks
-
ICE-3442 Component saveState restoreState
- Closed
- depends on
-
ICE-3303 Make InputFile's FileInfo Serializable
- Closed
-
ICE-3695 TreeNode do saveState restoreState
- Closed
-
ICE-3701 Tree navigatedNode currentNode state saving
- Closed
-
ICE-3702 SelectInputText selectedItem itemMap state saving
- Closed
-
ICE-3666 Non serialized properties of the components need to be defined as transient
- Closed
Show 1 more links (1 depends on)
Initially I implemented utility methods that use reflection, to do the state saving and restoration, which each of the components could use, so that adding or removing fields to/from a component would automatically result in the state saving doing the right thing. The problem was that the reflection code was noticeably slower than the hard coding approach. I tested several iterations of saving and restoring ice:commandButton 10,000 times. With hard coding it would usually take 0 milliseconds, and sometimes take 16 milliseconds. With reflection, the first few "lifecycles" of 10,000 iterations (where I'm simulating a component tree with 10,000 components), would take several hundred milliseconds. After, it would drop down to taking between 40 and 70 milliseconds. We deemed that too expensive in CPU time.
Next, we explored the idea of generating code, for each component class, so that we'd have the best of automatic correctness and fast execution. The problem was that we'd complicate the build process noticeably. As well, it would complicate debugging, since you'd effectivel have two sets of source files and class files, which we thought would be a problem for our users.
There was also the sub-option of code generation, which is class file modification, where we add state saving byte-codes to the class files, without intermediate source files. This still complicates things, and adds a certain degree of black magic, that could cause problems for users.
So, the current solution is to write a solid test platform, to verify the hard coding. It's not as automatic, but is very straightforward, and gives the most flexibility with the greatest simplicity.