Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 4.1
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces 4, ace:submitMonitor
-
Support Case References:Support Case #12955 - https://icesoft.my.salesforce.com/5007000000edYKn
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration
Description
For example, an application may want to use a general monitor that activates for any submit on the page, blocks the entire page, and presents a general busy indicator while the submit is in progress. In addition, the application may also want to provide a more specific monitor on say, a particular form on the page ("ClaimForm"). In that case, if the "ClaimForm" submits, it's monitor would block only the form and present a custom message (e.g. "Submitting Claim...").
Currently, both monitors would be triggered by the submit of the "ClaimForm", which may be undesirable. A more sophisticated approach would have a submitMonitor with a more specific scope override any others with more general scopes. That way, multiple monitors could be setup on a page and only one of them would be activated by a given submit.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Re-opened.
It would still be a useful improvement to have the ace:submitMonitor be able support multiple overlapping monitors with different levels of specificity in the page, while avoiding the possibility of having multiple monitors being displayed simultaneously.
For example, if the entire body of the document had a default submit monitor defined that presented a "Please Wait..." message, you could also define additional submit monitors on specific components in the page with more specific messages, such as on a form in a panel to add a new record to a database, which might present a message that says "Adding new Employee...", etc. So, it would be preferable if the submitMonitor was able to determine which instance of itself was most local to the component triggering the submit in the component tree and only present that monitor for any given submit.
Implemented the order of precedence for the monitors by executing only the monitor that is the closest (in DOM hierarchy) to the element that triggered the submit.
After the fixes made for
ICE-10284I believe the component can be already setup to work as described above. See comment: http://jira.icesoft.org/browse/ICE-10284?focusedCommentId=55341&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-55341