Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: EE-4.2.0.GA
-
Fix Version/s: None
-
Component/s: ACE-Components
-
Labels:None
-
Environment:All
-
ICEsoft Forum Reference:
-
Support Case References:
Description
The fix of issue ICE-10518 seems unneccacery.
The fix causes the problem that it isn't possible to disable blockUI for a specific form, if the context parameter 'org.icefaces.blockUIOnSubmit' is set to true.
Because ace:submitMonitor can be placed on every form, it should overwrite the context parameter org.icefaces.blockUIOnSubmit, which only can be disabled for specific pages.
Another way to fix the bugICE-10518, is to not use the attribute blockUI="@none" on the element ace:submitMonitor, if you want the blockUI to appear. If you want an blockUI to appear then you don't even have to use the element ace:submitMonitor, or you don't need to specify the attribute 'blockUI'.
The one who posted the question said the fix already in his description: "Removing the ace:submitMonitor from the page allows the ui blocker to work correctly. ". He should have just removed the ace:submitMonitor, and the ui blocker allways worked correctly, the use of ace:submitMonitor was only faulty used.
I've posted a question also on StackOverflow regarding this: https://stackoverflow.com/questions/54180650/setting-blockuionsubmit-for-a-specific-form
And added a comment on the bugICE-10518: http://jira.icesoft.org/browse/ICE-10518
The fix causes the problem that it isn't possible to disable blockUI for a specific form, if the context parameter 'org.icefaces.blockUIOnSubmit' is set to true.
Because ace:submitMonitor can be placed on every form, it should overwrite the context parameter org.icefaces.blockUIOnSubmit, which only can be disabled for specific pages.
Another way to fix the bug
The one who posted the question said the fix already in his description: "Removing the ace:submitMonitor from the page allows the ui blocker to work correctly. ". He should have just removed the ace:submitMonitor, and the ui blocker allways worked correctly, the use of ace:submitMonitor was only faulty used.
I've posted a question also on StackOverflow regarding this: https://stackoverflow.com/questions/54180650/setting-blockuionsubmit-for-a-specific-form
And added a comment on the bug
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Has anyone viewed this BUG? I would really like to know if this is a real problem or if I'm understanding something in the wrong way.
Show
Oscar Stigzelius
added a comment - Has anyone viewed this BUG? I would really like to know if this is a real problem or if I'm understanding something in the wrong way.
According to ICE-7740 and Comment on ICE-7740 is that there would be a functionality that could control submits for specified components.
"This would be similar to the current blockUIOnSubmit behaviour, but specified per component." [ICE-7740].
"There should be an order of precedence such that a more specific monitor will override a more general one, in cases where more than one monitor might be in effect for the same submit." [Comment on ICE-7740]
Whit this comment I want to strengthen the argument that ace:submitMonitor should be able to override the context parameter org.icefaces.blockUIOnSubmit which was taken away here: ICE-10518.