Populate values based on Multi select list data
I have a multi select list control property( say Id) which is sourced using a data page. There is one more multi select list control property(Name). My requirement is based on the first multi select inputs the second one need to populate.
how can I send a page list property as a parameter to the second multi select list?
How to achieve this requirement?
Updated: 4 Jun 2019 8:00 EDT
Pegasystems Inc.
FR
Hello,
What Pega version are you using? The UI Gallery should have MultiSelect examples:
Pegasystems Inc.
IN
Hi Vinoth,
Trying to understand your requirement, are you trying to populate the second multi select using any report definition/datapage?
The results of the first multi select will be stored in the pagelist configured. On change of the first multi-select post the value to the pagelist and run a data transform/activity to loop over the pagelist property to get your required data from it.
This data can be formatted and passed to the second multi-select source(RD/DP) accordingly.
Hope it helps implementing your requirement.
Thanks.
Optum
IN
Hi,
The concept is you are describing here is called cascading relationships on list based controls. The selection of a value in one control directly impacts the contents of a second control.
The attached document illustrates an example for a drop down control. But you could try the same approach for a multi select control.
CYBG
GB
Hi Srinivas,
I have a question on your solution in the Word document: It appears that you are suggesting writing a separate report definition rule for every type of drop-down. Thus if you had a cascade that went, say, 10 levels deep, then you would need 10 RDs. Is that correct?
If so, that sounds very inefficient from a maintenance perspective. Surely it would be better to have a single, common method that handled all such drop-downs (i.e. allowed infinite cascading)? This is possible using a common table for all such drop-down lists with each entry having a pointer to its parent entry, if applicable. Thus the classic cascading example of Country-State-City would have entries in the table for Country (no parent), State (parent = Country) and City (parent = State). Each type of data is selected for the drop-down based on parameters entered, primarily the entry type (e.g. City) and its parent (e.g. State).
The main benefit of such an approach is that the only code required to add new drop-downs with different values is the adding of the drop-down to a section, effectively making this a zero-code solution once the initial build is done.
Hi Srinivas,
I have a question on your solution in the Word document: It appears that you are suggesting writing a separate report definition rule for every type of drop-down. Thus if you had a cascade that went, say, 10 levels deep, then you would need 10 RDs. Is that correct?
If so, that sounds very inefficient from a maintenance perspective. Surely it would be better to have a single, common method that handled all such drop-downs (i.e. allowed infinite cascading)? This is possible using a common table for all such drop-down lists with each entry having a pointer to its parent entry, if applicable. Thus the classic cascading example of Country-State-City would have entries in the table for Country (no parent), State (parent = Country) and City (parent = State). Each type of data is selected for the drop-down based on parameters entered, primarily the entry type (e.g. City) and its parent (e.g. State).
The main benefit of such an approach is that the only code required to add new drop-downs with different values is the adding of the drop-down to a section, effectively making this a zero-code solution once the initial build is done.
We achieved this with a single, 8-step activity - without embedded Java - and a single external table (and a small class to hold the properties). All drop-downs in the application use this model without the need for further coding. If run-time efficiencies are required then the data can be loaded into a data page rather than looked-up from the DB every time (we did not do this as data changes made externally to the PRPC application were required to take effect immediately without waiting for a data page reload).
If such a solution is desired then I would be happy to share the design pattern.
Cheers,
Mike.