Back ForwardHow to build for change

Business environments change, sometimes suddenly, in response to external change or internal decisions. PRPC allows you to design and implement applications that respond to change with agility and efficiency.

By recording business practices and policies in records rather than in code, all PRPC applications provide a degree of modularity and transparency that can simplify maintenance. For example, line managers can review and comment on a business process presented as a Process Modeler diagram, even without knowing Process Modeler how to maintain a flow record.

To go beyond this basic PRPC benefit, application developers can delegate responsibility for updating selected important parts of each application to business managers. This promotes:

Which records can managers update?

Users who have the PegaRULES:WorkMgr4 access role (or other roles that include the UpdateLimitedForm privilege) can view and update the leftmost tab of any delegated record. They can also view and update the History tab.

By design, the leftmost tab of the forms for ten rule types provides access to fields most likely to change over time. Although records of any type can be delegated, managers are most likely to learn and understand the following types:

Designing for delegation

To empower managers to change selected records:

  1. Identify during design which records are useful to delegate to managers to maintain.
  2. Choose record names and property names that are meaningful in the business context.
  3. Choose Short Description text carefully for properties that may be referenced in the records.
  4. After initial testing is complete, copy the records into a ruleset containing only the delegated records. This segregates any later changes to them from the rest of the application.
  5. Delegate the records, and confirm that they can be accessed from the manager's dashboard, with meaningful labels.
  6. Provide appropriate training and documentation to line managers.
Definitions delegated rule
Related topics How to delegate a rule
PRPC documentation

UpSysAdmin category

2. Set up a SpellChecker Properties data instance

The spellchecker software operates on the PRPC server, using the dictionaries, features, and settings identified in a Data-SpellChecker-Properties instance. See About SpellChecker Properties data instances.

3. Update harnesses

Spellchecking is available only for user forms based on harnesses that use the SmartFrames form of the Layout tab and include the spellchecker icon.

To include the spellcheck capability in a user form:

  1. Open the harness
  2. Click the down arrow (Menu) in the Basic control group (Basics) and select the Icon control (Button). Drag the Icon control to the cell or header area that is to contain it. When the pointer changes shape to indicate that a single cell or header is selected, release the mouse button.
  3. Click (Magnifying glass) to display the Cell Properties panel.
  4. Complete the Cell Properties panel. Select Spell Checker as the Type. The corresponding icon appears on the form (Spellcheck). See Harnesses, Sections, and Flow Actions — Adding an Icon.
  5. Save the Harness form.
  6. Test.

4. Control which properties support spellchecking

This step is optional. By adjusting the HTML representation of a property, you can control which properties can be spellchecked. (Users can check spelling can only for properties presented in read-write mode, which allows the corrected spellings to be entered.)

By default, spellchecking is enabled for input fields that reference Text Area (pxTextArea) and disabled for Text Input (pxTextInput) auto-generated control rules. This functionality cannot be modified.

Non-auto-generated controls

By default, spellchecking is enabled in the non-auto-generated control rule TextArea that produces an HTML tag of the form:

<INPUT TYPE="TEXTAREA" ... >

To disable spellchecking for a property that is represented with a TEXTAREA tag:

  1. Open the property.
  2. Open the control rule referenced in the property.
  3. Copy and save the control rule into an application RuleSet, changing the name.
  4. Click(magnifying glass) to edit the HTML text of the copy. Add the HTML attribute SPELLCHECKENABLED="false" to each <TEXTAREA> tag.
  5. Save the new control rule.
  6. Update the property to reference the new control rule.

By default, spellchecking is disabled in the non-auto-generated control rule Text that produce an HTML tag of the form:

<INPUT TYPE="TEXT" ... >

To enable spellchecking for a property that is represented with a TEXT tag:

  1. Open the property.
  2. Open the control rule referenced in the property.
  3. Copy and save the control rule into an application RuleSet, changing the name.
  4. Clickto edit the HTML text of the copy. Add the HTML attribute SPELLCHECKENABLED="true" to each <INPUT TYPE="TEXT" > tag.
  5. Save the new control rule.
  6. Update the property to reference the new control rule.

5. Set user locale and privileges

When the spellcheck icon is visible at runtime, any user who can update the work item can perform the spellcheck. The current locale of the user determines which SpellChecker Properties instance applies, and so which dictionaries apply. Users can change their locale through Windows workstation facilities, the Locale Settings tool, or by running an appropriate activity.

Only users who hold the privilege @baseclass.AddtoDictionary can insert new words into a user dictionary. Such users must also have the ability to update rules in the RuleSet version that contains the user dictionary (a text file rule).

Related topics About control rules
About SpellChecker Properties data instances
About the Locale Settings tool
Standard rules Atlas — Initial SpellChecker Properties data instances

UpUser Interface category