Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 3.2
-
Fix Version/s: 3.3
-
Component/s: ACE-Components, Sample Apps
-
Labels:None
-
Environment:ICEfaces3 trunk revision# 33310
Fails with Mojarra or Myfaces
-
Assignee Priority:P1
Description
The submitMonitor triggers busy state when submits are made outside of the assigned 'for' area. This only occurs when blockUI=@none and can be easily reproduced in the showcase demo...
1) Load showcase and navigate to ace:submitMonitor demo
2) Ensure 'region to listen to' is set to Demonstration Panel. And 'What to block' is set to Nothing.
3) Type a new value into one of the label fields and press tab (or alternatively click on the + to show the source code)
Notice the submitMonitor triggers busy state for a brief moment when it should only be monitoring submits from the Demonstration Panel.
1) Load showcase and navigate to ace:submitMonitor demo
2) Ensure 'region to listen to' is set to Demonstration Panel. And 'What to block' is set to Nothing.
3) Type a new value into one of the label fields and press tab (or alternatively click on the + to show the source code)
Notice the submitMonitor triggers busy state for a brief moment when it should only be monitoring submits from the Demonstration Panel.
Issue Links
- depends on
-
ICE-8965
onElementUpdate doesn't execute all listeners
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
There were interactions between ICE-8965 and ICE-9844, where onElementUpdate not cleaning up the submitMonitor allowed it to appear to work in some cases where the new create code was not initialising due to a lingering widgetVar. So having the cleanup code ran appeared to break things. This made it appear that it was using the old cfg.monitorFor value from the last page refresh.
Show
Mark Collette
added a comment - There were interactions between ICE-8965 and ICE-9844 , where onElementUpdate not cleaning up the submitMonitor allowed it to appear to work in some cases where the new create code was not initialising due to a lingering widgetVar. So having the cleanup code ran appeared to break things. This made it appear that it was using the old cfg.monitorFor value from the last page refresh.
Tweaked the showcase sample to add a delay to the input elements in the configuration panel, so if they cause a submit then it will last longer, like the Submit button in the demonstration panel, to better illustrate the submitMonitor.
icefaces3 trunk
Subversion 33544
Show
Mark Collette
added a comment - Tweaked the showcase sample to add a delay to the input elements in the configuration panel, so if they cause a submit then it will last longer, like the Submit button in the demonstration panel, to better illustrate the submitMonitor.
icefaces3 trunk
Subversion 33544
submitMonitor.for property generated getter/setter EL evaluation wasn't working since it was using forVal.name() which is "forVal" as the name() method is the enum's name and not the annotation's name.
This means that all of the components with for properties were not working if tied to ValueExpressions, they would just return null, or possibly whatever their default value was.
This is the list, along with their unaliased names from the Meta classes:
contextMenu.forValue
draggable.forValue
droppable.forValue
message.forValue
messages.forValue
printer.forValue
resizable.forValue
submitMonitor.For
tableConfigPanel.forTarget
tabSetProxy.For
tooltip.forValue
QA reproduced the EL value being null with several of the components from the list, and confirmed the fix after the generator fix commit.
icefaces3 trunk
Subversion 33476