Question
Wipro
US
Last activity: 16 Apr 2017 11:07 EDT
promptFieldValue Vs DropDown with datapage
Hi,
We have a requirement to present the regions in a dropdown. we have 2 options here.
1.We have a OOTB control promptFieldValue which lists all the field values with the field name as region and will present in dropdown or table type as FieldValue in the property rule form.
2. We can also create a datatype and maintain all the regions in a DB table. and Use the drop down control configured with a data page to list the same.
So here which is the best practice to follow.
Thanks.
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Cognizant Technology Solution
US
I think it depends on the requirement as well. Are you having specific regions which will only be listed or there is a chance of having arbitrary regions as well. Problem with the PromptFieldValue is, this control will only load values from some pre-existing localized region values. Hence, any value other than the ones exist in Pega will need to be created a separate Field Value . If the list is unknown then again, the number of such field values will have a chance to grow exponentially. On the other hand, maintaining a Data Type will be lot easier for new values.
Wipro
US
Thank you.
I have a specific set of regions defined by my organization across all applications. these may grow as the organization grows across the regions.
But I feel its the same for both options in the view of maintaining the instances.
in option1 we have update/create rules and in option 2 we have to update/create data instances.
My question is which is the best practice to follow whether to maintain it as a rule or data instance in this case.
Knowledge Experts SA
FR
In promptFieldValue, one cannot add or remove more values at runtime after production without rule being checkedout and checkedin. The approach is not build for change. Rest explains.
Wipro
US
Field values are also supports the changes. if we have any changes we can update/create the rule and move the same rule to higher environments.
I could not get your idea on build for change here.
Cognizant Technology Solution
US
Changing Data type is definitely a better approach and easy to maintain. Creation of Field Values whenever new region created will not be a good approach as this is a new rule creation and not exactly a configuration.
Wipro
US
Still I dont understand why it is a better approach as there is no tracking if any mistake happens.
PegaRULES itself is a rule based system, then how come a rule becomes a maintanance critical.
In my perspective maintaining field values is easy than data types as they have additional history tracking.
Cognizant Technology Solution
US
Pega rules is not a maintenance critical thing. But compared to everytime create a new rules(Field Value) it is better to create a new row in a Data Type is definitely better and less memory consuming task. Next thing is, think of a situation where your application is in production and there might be a different region added. So, it is a good practice to delegate this kind of things to users. So, creation of a new Field Value is not a task which can be done by user, but if you delegate a Data Type to user, they can easily maintain it.So, when we talk about Best Practice, all these things should be taken into consideration.