Drop Down Values
I am maintainign the values for drop down fields in a table. The same table has values for all projects/implementations and fields. So i have three columns project, field and value. What is the best way to retrieve this. In dynamic select we have options for Clipboard Page/Activity/Report Def/List View. Which of them work fine when we pass parameters to them. I checked for Report-Def and I was not abel to pass params into Report def using the Dynamic Select control. Activities seem to be the 5.5 way but not 6.2. Please guide me whats the best way.
Pegasystems Inc.
US
In 6.X, I implemented chained Dynamic Select behavior multiple times using a Node-level declare page for the root drop-down, project, in your case.
I then used Thread-level Declare Pages for the second and third drop-downs, i.e, field and value in your case.
A "Fresh When" rule was configured on each Thread-level Declare Page.
The When rule reacted to a change in value of the property that is set "upstream", i.e., the one it is chained to.
Each Declare Page in this design can invoke a Report Definition vs callng an Activity.
The problem you are experiencing is not being able to pass parameters to the Report Definiton.
As opposed to passing a parameter to a Report Defintion, you can refer a Declare Page property within a filter condition, e.g., .ProjectID = Declare_Project.ProjectID, .
Note that Dynamic Select controls are deprecated in 7.1, hence using a Declare/Data Page approach now will be in line with future best practice.
Pegasystems Inc.
US
Further carifying my previous post.
You need three List-type Declare Pages for the list displayed by each dropdown. Each of these are read-only.
For a Report Definition filter condition, you can use a Thread-local, Page-type clipboard page as opposed to relying on parameters.
When the Project dropdown selection is made, the selected value would need to be set into to the Clipboard page that the Report Definiton references.
It is possible to have a Page-type Thread-level Declare Page , e.g., Declare_Project, react to some change, e.g., to pyWorkPage.ProjectID, then set its own property equal to that value.
However your Report Definiton could simply filter directly on pyWorkPage.ProjectID as opposed to Declare_Project.ProjectID.
It defeats the purpose if a Page-type Declare Page has to use an Activity to set its value, plus the solution is considerably less complex not having two additional Fresh-When-driven Declare Pages if you don't need them.
Where you might need or want the additional Pages is when you are implementing something like a re-usable "component" such as a shopping cart-like Product Selector that uses Data classes such as Data-ProductCategory and Data-Product, where a ProductCategory has a .ParentCategory property.
Further carifying my previous post.
You need three List-type Declare Pages for the list displayed by each dropdown. Each of these are read-only.
For a Report Definition filter condition, you can use a Thread-local, Page-type clipboard page as opposed to relying on parameters.
When the Project dropdown selection is made, the selected value would need to be set into to the Clipboard page that the Report Definiton references.
It is possible to have a Page-type Thread-level Declare Page , e.g., Declare_Project, react to some change, e.g., to pyWorkPage.ProjectID, then set its own property equal to that value.
However your Report Definiton could simply filter directly on pyWorkPage.ProjectID as opposed to Declare_Project.ProjectID.
It defeats the purpose if a Page-type Declare Page has to use an Activity to set its value, plus the solution is considerably less complex not having two additional Fresh-When-driven Declare Pages if you don't need them.
Where you might need or want the additional Pages is when you are implementing something like a re-usable "component" such as a shopping cart-like Product Selector that uses Data classes such as Data-ProductCategory and Data-Product, where a ProductCategory has a .ParentCategory property.
Those pages would capture upstream-selected values as opposed to forcing pyWorkPage to capture them. When the product is identified, only then is an "Add to Cart" buttom clicked that appends to a .ProductList PageList that each case class (pyWorkPage.pxObjClass) inherits.
Alternatively you could have it both ways by having the Product Selector be an embedded page on the case. The embedded page would not only capturing previously selected values it would also capture the "Add to Cart" .ProductList.