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
In ACE 2, our components solely had MethodExpression properties to invoke when broadcasting events, as was typical with our compat components. With ACE 3, we introduced the use of ace:ajax as a means of specifying server-side execution and rendering, as well as client-side event handling.
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.
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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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.
Show
Mark Collette
added a comment - 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.
Show
Mark Collette
added a comment - The event re-inheriting won't work for the built-in events like ActionEvent and ValueChangeEvent.
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.