Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 3.1.0.BETA1
-
Fix Version/s: None
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ACE
Description
The server-side event handling has become fragmented into three categories:
1. Old ACE components with an ACE 2 heritage continuing to use component MethodExpressions, where ace:ajax solely controls the component executing.
2. Early ACE 3 components using ace:ajax listener for the server-side event handling, with no equivalent MethodExpression existing on component.
3. Some newer ACE 3 components using both component MethodExpressions and ace:ajax listener, but not necessarily with the same event type, which could be confusing for application developers.
We need to migrate all of our components to #3, but with a single event type used for a particular event, whether it's for the component or ace:ajax.
Issue Links
- depends on
-
ICE-8261
IceClientBehaviorHolder specify their AjaxBehaviorEvent subclass
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [] | |
| Fix Version/s | 3.2 [ 10338 ] |
For unified events, it should be possible to make all of our events extend javax.faces.event.BehaviorEvent, and when the renderer creates and queues it, simply give null as the Behavior parameter, and when the Behavior queues it, it will have a Behavior. In broadcast we can then use that to know what to do with it.
Having both the component MethodExpression and ace:ajax listener specified should entail both being invoked with the event.
The event re-inheriting won't work for the built-in events like ActionEvent and ValueChangeEvent.
| Fix Version/s | 3.3 [ 10370 ] | |
| Fix Version/s | 3.2 [ 10338 ] |
| Assignee | Mark Collette [ mark.collette ] |
| Assignee Priority | P2 [ 10011 ] |
| Fix Version/s | 3.4 [ 10770 ] | |
| Fix Version/s | 3.3 [ 10370 ] |
| Assignee Priority | P2 [ 10011 ] | P1 [ 10010 ] |
| Assignee | Mark Collette [ mark.collette ] | Ken Fyten [ ken.fyten ] |
| Assignee Priority | P1 [ 10010 ] |
This requires a public API change and we missed the opportunity to make this change for 4.0, marking Won't Fix.
| Status | Open [ 1 ] | Closed [ 6 ] |
| Fix Version/s | 4.0.BETA [ 10770 ] | |
| Resolution | Won't Fix [ 2 ] |
Some things I noticed in Dialog.queueEvent
that we'll want to fix there and elsewhere we might make the same mistakes:
if(eventName != null && eventName.equals("close") && event instanceof AjaxBehaviorEvent) {
...
closeEvent.setPhaseId(PhaseId.APPLY_REQUEST_VALUES);
There's a nested component issue, where we should only mess with the event if it's from us, since child Dialog events bubble up through us. Look at UICommand.queueEvent
as an example of dealing with this.
AjaxBehaviorRenderer.decode
uses immediate for the event phaseId, but that's tossed out here to hard code the phaseId. Should probably carry forward the phaseId when substituting the event. Or possibly should wrap the event instead of substitute.