Filters and command handlers can more easily manipulate the instance list by invoking simplified methods in a shared instance list 'controller. To do this all they have to do is
RAMP 5250 navigation scripts cannot declare a VL reusable component and invoke its methods, but what they can do is signal events, so if 'something' is listening for the events they signal, then it can invoke the manager methods on their behalf.
Typically the 'something' that is listening for RAMP script events is a filter, which has an EVTROUTINE something like this in it:
Evtroutine Handling(#Com_owner.avEvent) WithId(#EventId)
WithAInfo1(#AInfo1) WithAInfo2(#AInfo2) WithAInfo3(#AInfo3)
Case #EventId.Value
When (= UPDATE_EMPLOYEE_5250)
#EmployeeController.UpdateListDetails ListManager(#avListManager)
ForEmpno(#AInfo1)
When (= DELETE_EMPLOYEE_5250)
# EmployeeController.DeleteListDetails ListManager(#avListManager) ForEmpno(#AInfo1) inDepartment(#AInfo2) InSection(#AInfo3)
EndCase
Endroutine
A filter with this code in it is listening for events named UPDATE_EMPLOYEE_5250 and DELETE_EMPLOYEE_5250. When it receives one of them it routes the request into the shared instance list controller.
Of course there needs to be an agreed protocol between the RAMP script and the filter regarding how the employee key details are passed in the event payload parameters.
When a RAMP script detects a 5250 activity that means the instance list needs to be updated (e.g. deleting or updating an employee) it would execute JavaScript script coded something like this:
AVSIGNALEVENT("DELETE_EMPLOYEE_5250", "BUSINESSOBJECT", objListManager.AKey1[0], objListManager.AKey2[0], objListManager.AKey3[0] );
Or
AVSIGNALEVENT("UPDATE_EMPLOYEE_5250", "BUSINESSOBJECT", objListManager.AKey3[0]);