Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
Description
In Mojarra2's UIData.keepSaved, they just do the following, instead of that whole FacesMessage while loop that we do in UISeries.keepSaved:
FacesMessage.Severity sev = context.getMaximumSeverity();
return (sev != null && (FacesMessage.SEVERITY_ERROR.compareTo(sev) >= 0));
The difference of course being that we track whether a child of the container has failed validation, whereas stock JSF sees if any component in the view has failed validation.
One bad scenario with our existing way, would be if you have two different dataTables in one form. Something in dataTable A fails validation, so the whole form, and thus both dataTable A and B have failed validation. But dataTable B detects no FacesMessages for its components, so it throws out its state, losing any inputted values therein. I'd rather keep state potentially too long, that apps can just clear themselves, than lose state that unrecoverable. Maybe we should adopt their optimisation.
FacesMessage.Severity sev = context.getMaximumSeverity();
return (sev != null && (FacesMessage.SEVERITY_ERROR.compareTo(sev) >= 0));
The difference of course being that we track whether a child of the container has failed validation, whereas stock JSF sees if any component in the view has failed validation.
One bad scenario with our existing way, would be if you have two different dataTables in one form. Something in dataTable A fails validation, so the whole form, and thus both dataTable A and B have failed validation. But dataTable B detects no FacesMessages for its components, so it throws out its state, losing any inputted values therein. I'd rather keep state potentially too long, that apps can just clear themselves, than lose state that unrecoverable. Maybe we should adopt their optimisation.
Issue Links
- blocks
-
ICE-5525 Regression: UISeries.keepSaved performance
- Closed
I ran in some challenges while trying to create a test case for this issue.
1. When I made an inputText fail validation, it threw an exception about not finding some resource bundle, which I'd ran into before in
ICE-3896. I dug into that, seeing if my browser locale was correct, and if I needed to include the locale configuration in my faces-config.xml, but then I found out it was my fault, I'd built my own JSF jars that somehow didn't include the required Messages.properties files.2. I tried using List<String> as my data models for my test case, which didn't seem to work properly. I remembered running into this in the past, and replaced them with List<ClassWithStringField>, and changed the facelets page to use a field off of the List element instead of the List element directly, and then I started getting the expected behaviour.
3. For my test case, I made two separate forms, each with their own UISeries with required inputText child. I tried covering all of the possible input value combinations, but that wasn't useful, since the necessary test involved multiples interactions in a specific sequence, and not a single step with a given set of inputs.