Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.0.0
-
Component/s: Framework, ICE-Components
-
Labels:None
-
Environment:ICEfaces 2.0 Glimmer w/ Sparkle components
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration
Description
For example, say you have a form with 3 inputText components in it, each with an associated message component. Each inputText component has "partialSubmit=true, required=true" specified:
1. Tab into inputText #1, then tab out without entering anything -> message comp. for that comp. displays "Required" error message.
2. Tab out of inputText #2 without entering anything -> message comps. for both inputText #1 and #2 should both now display the "required" error messages (std. JSF behavior will clear the message for inputText #1 as it wasn't executed when inputText#2 was via partialSubmit).
Note that partialSubmit in this case is equivalent to "execute=this, render=all".
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Mark says:
Instead of a component, this might fit better as a framework feature.
When a component is executed, right before decoding it marks itself as valid. Then, as it fails conversion or validation, it marks itself as invalid, and generated a FacesMessage, which it puts into the FacesContext. JSF 2 add some field about failing validation, which I'm not sure exactly what the nuanced difference is from being invalid. Then, at the end of the lifecycle, the FacesMessages are cleared away. We just need some code to save all the FacesMessages away, so that when we then do subsequent lifecycles, as we then execute whichever sub-tree of the component tree, whatever is not executed, and yet is still invalid, and possibly what will be rendered (needs discussion), will have its FacesMessages re-added to the component tree. The framework, in conjunction to the PartialViewContext, may have access to this information, and be able to accomplish this. But a component probably won't have access to that information.
Okay, current thinking is to have the framework handling the task of cacheing the faces-messages, and then offer a custom component(s) that provides the necessary behaviour, leveraging the framework support.
We should identify what to do with global FacesMessage(s), that don't have an associated clientId.
We'll re-add global messages, when not executing everything, if the old global message's summary and detail don't match any new global.
One issue with this solution is that even with a full execute, only the current form actually executes. So, if you have faces messages created in form A, then submit form B, you'll still lose the faces messages from form A, since it won't execute, even though it's a full execute.
Initial commit of faces message recovery, for faces messages that are: global, from components, where there was a partial execute. This leaves scenarios of full execute, but where the component is either in or out of the submitting form.
Subversion 22322
Commented out some print statements.
Subversion 22342
Switched the saving of faces messages to happen pre-render, so that they'll survive state saving, when using the state saving strategy of not keeping the view root. Also, found a deficiency in the algorithm for detecting if a component was executed, when the form's prependId property is false. Fixed that with a visitTree implementation that does not require interpretation of clientIds to determine component parentage.
Subversion 22377
Added a sample application for testing in a single form, with h: components.
icefaces2\samples\test\messages
Subversion 22378
Subversion 22379
Added Instructions.rtf file to the icefaces2\samples\test\messages test application, detailing the steps to take to verify the functionality.
Subversion 22393
We should now support the typical scenarios of f:ajax and singleSubmit scenarios, inside a single form, requiring persisting of FacesMessage objects that are global and are tied to components.
Now suppress adding component messages when those messages already exist for that component. This a work-around for an issue where we're duplicating messages.
Subversion 22841
Perhaps creating custom message(s) components could provide this functionality.