I will extend previous sample application - ADF Region Communication - Data Exchange Through Shared Data Control Java Class and will describe how you can enrich it and apply contextual events. Even you would think about contextual events as about something cool, be careful - its not a panacea for all problems, and should be used carefully to avoid system architecture complexity explosion. While its not always true, I would prefer to use contextual events mostly for dependent region refresh, without passing payload directly. When system grows, its easier to track data references from Data Control Java class (see referenced blog post above), than contextual events payload variables. Its possible to refresh dependent region through ADF bounded task flow parameters - but contextual events provide better separation level between two regions.
Download sample application - ADFRegionCommunication2.zip. Two regions are implemented - Jobs and Employees:
Based on user selection, second region is refreshed - rows for selected job are highlighted:
If selection is changed, dependent region is refreshed as well:
As in previous blog article referenced above, user can insert new row - CreateWithParams operation will get JobId selected from the first region:
JobId data is passed as before, through Data Control Java class. Region is being refreshed through contextual event. This event (jobIdSelectionEvent) is generated on row selection and is triggered from table selection listener method:
Event (jobIdSelectionEvent) is declared in page definition file for Jobs region:
Main page provides contextual event mapping between two regions - producer (headerflow1) and consumer (detailflow1):
Finally consumer region assigns contextual event to be handled by refreshDetailTable method:
This method is coming from managed bean associated with consumer region:
In order to be able to map this method from consumer region page definition, you need to create Data Control for managed bean class:
It is good practice to generate Data Control for managed bean from early beginning, while there are ADF classes declared yet. Otherwise generated Data Control will include attributes from ADF classes and will be unnecessary big. There is no option to deselect class objects from being included into Data Control.
Row color is controller by expression language, we are referencing Data Control Java class to retrieve current selection from header region and compare it with each row value from detail region:
Download sample application - ADFRegionCommunication2.zip. Two regions are implemented - Jobs and Employees:
Based on user selection, second region is refreshed - rows for selected job are highlighted:
If selection is changed, dependent region is refreshed as well:
As in previous blog article referenced above, user can insert new row - CreateWithParams operation will get JobId selected from the first region:
JobId data is passed as before, through Data Control Java class. Region is being refreshed through contextual event. This event (jobIdSelectionEvent) is generated on row selection and is triggered from table selection listener method:
Event (jobIdSelectionEvent) is declared in page definition file for Jobs region:
Main page provides contextual event mapping between two regions - producer (headerflow1) and consumer (detailflow1):
Finally consumer region assigns contextual event to be handled by refreshDetailTable method:
This method is coming from managed bean associated with consumer region:
In order to be able to map this method from consumer region page definition, you need to create Data Control for managed bean class:
It is good practice to generate Data Control for managed bean from early beginning, while there are ADF classes declared yet. Otherwise generated Data Control will include attributes from ADF classes and will be unnecessary big. There is no option to deselect class objects from being included into Data Control.
Row color is controller by expression language, we are referencing Data Control Java class to retrieve current selection from header region and compare it with each row value from detail region:
I am curious how this differs from PPR. I realize PPR is directly coded into the controls, but is there any real downside? I could see contextual events being useful in a portal perhaps. Just trying to decide which way to go for my usecase.
ReplyDelete