Maximize rule reuse with page name parameters
This presentation is part of the Reusability and Specialization e-Learning Course.
Transcript
By parameterizing page names, rules can be executed on an object regardless of the current page name of that object. The opposite of parameterizing page names is to hard code them.
A hard-coded page name is any explicit page name that shows up in a rule – for example, pyWorkPage, MyHelperPage, or NewAssignPage.
The out of the box activity Work-AddCoveredWork is a good example of using Page Name parameters to avoid hard coding a page name. The parameter CoverPage of this activity is defined as Data Type Page Name, which tells PRPC that this parameter will define a page name that is expected to be on the clipboard. The actual page name will be passed in the parameter.
By using the same value of the Name field on the Parameter Tab and the Page Name field on the Pages & Classes Tab, PRPC can properly perform validation and use SmartPrompt at design time.
Even though CoverPage is explicitly labeled within the AddCoveredWork activity, there will never actually be a page name cover page on the clipboard. PRPC will handle the association, since CoverPage was defined as a parameter page.
It is nearly impossible to avoid named pages everywhere, especially in the outermost activities of your process. If we drill down into the activity AddCovered, we can see how to execute an activity that has a Page Name parameter defined under it. We pass in the actual name of the page to the CoverPage parameter. However, we are passing in PyWorkCover, which will be referred to as CoverPage inside the AddCovered work activity.