Avoid Duplicated Instance List Code

Avoid Duplicated Instance List Code

If you have many different filters then you may end-up with duplicated instance list code. This may be annoying if a designer decides to change the key structure or additional columns that are used in an instance list, because you have to change all the filters to use the new instance list format.

To avoid this, do what you always do, and centralize the instance list manipulation code into one Visual LANSA reusable part that all your filters share.

Imagine a Visual LANSA reusable part named EMPMNGR that adds employees to an instance list in 3 different ways: 

BEGIN_COM ROLE(*EXTENDS #PRIM_OBJT)

 

* Perform employee searches and add to the instance list

 

MthRoutine PerformSearch 

Define_Map *Input #vf_lm002 #ListManager Pass(*By_Reference)

Define_Map *Input #std_num #SearchType

Define_Map *Input #EmpNo #UseEmpNo Mandatory(' ')

Define_Map *Input #SurName #UseSurName Mandatory(' ')

Define_Map *Input #PostCode #UsePostCode Mandatory(0)

Define_Map *input #Prim_Boln #Clear mandatory(true)

 

Invoke #ListManager.BeginListUpdate

 

If (#Clear)

Invoke #ListManager.ClearList

Endif

 

Case #SearchType

 

when (= 1)

Select fields(*all) from_file(pslmst) with_key(#UseEmpno) Generic(*Yes)

#Com_Owner.AddEmployeetoList ListManager(#ListManager)

Endselect

 

when (= 2)

Select fields(*all) from_file(pslmst2) with_key(#UseSurName) Generic(*Yes)

#Com_Owner.AddEmployeetoList ListManager(#ListManager)

Endselect

 

when (= 3)

Select fields(*all) from_file(pslmst) where(#PostCode = #UsePostCode)

#Com_Owner.AddEmployeetoList ListManager(#ListManager)

Endselect

EndCase

 

Invoke #ListManager.EndListUpdate

 

Endroutine

 

* Add an employee to the instance list

 

MthRoutine AddEmployeetoList Access(*Private) 

 

Define_Map *Input #vf_lm002 #ListManager Pass(*By_Reference)

 

#FullName := #GiveName + " " + #SurName

 

Invoke Method(#ListManager.AddtoList) Visualid1(#Empno) Visualid2(#FullName) Akey1(#Deptment) Akey2(#Section) Akey3(#Empno) AColumn1(#Phonehme) AColumn2(#Address1) nColumn1(#PostCode)

 

Endroutine

 

END_COM

 

 

Now imagine you have five employee filters like this:

 

If these filters each declared the shared VL reusable part like this:

DEFINE_COM CLASS(#EMPMNGR) NAME(#EmployeeManager) scope(*Application)

 

then they can perform their respective searches by using a single command like this:

Invoke #EmployeeManager.PerformSearch ListManager(#avListManager)

       SearchType(1) UseEmpNo(#EmpNo) Clear(true)

 

Or like this:

Invoke #EmployeeManager.PerformSearch ListManager(#avListManager)

       SearchType(2) UseSurName(#SurName) Clear(false)

 

It is worth noting:

• That the employee manager #EMPMNGR object uses EXTENDS(#PRIM_OBJT). This defines it as a primitive object that has no visual context.

• The use of Scope(*Application) when declaring #EMPMNGR. This makes sure that only a single #EMPMGR object is ever created and it is shared by all your filters or command handlers. 

• That the filters might not have to have any search logic at all in them, nor would they have to directly access the database. All their search and database activities could be handled by the common shared #EMPMNGR object. 

• If you need to change the employee instance list keys or the additional columns you now only need to change and recompile #EMPMNGR.