Chapter 22
Inside the components
The scenarios say what to do. This chapter says what a finished component actually does when you press it: the order of its steps, what it protects against, and the odd workarounds that exist because something once broke.
Pega 24 – 26
Words you will meet
- Buttons
- Layouts
- Workarounds
Read this first
The parts you do not see in a demo.
A demo shows the happy path. Real components spend most of their code on everything else: a click while one is already running, a data page that answers in an odd shape, a theme that lacks a value, a keyboard user whose focus would be lost. This was written by reading how a real library runs, and told without any client names.
Tables, grids and search have their own chapter. Here are the buttons, layouts and displays, and the habits every component shares.
Under the hood
Buttons, layouts and displays.
Button that runs a data page
Press once, run server logic, tell the person what happened.
What happens, in order
- 1Guard against repeats: a second click while one is running does nothing.
- 2Read the settings (parameters, result check, refresh target). Each is parsed once per click.
- 3Resolve the parameters from Pega itself, never from a typed string. Stop early if a value is missing.
- 4Call the data page through Pega’s own data API.
- 5Check the data page’s own answer for a failure it reports in a field.
- 6Only after success, refresh the view the author named.
- 7Report the outcome as one of a few fixed states, so the same click always gives the same result.
What it guards against
- Pega’s data API runs the request, so the user’s session, access group and the data page’s own rules decide what comes back. Nothing here widens access.
- Every settings parser returns either a typed value or a plain-English reason, so a mistake in the settings panel becomes a clear setup message naming the setting, never a silent wrong call or a crash.
- Every failure has the same shape: what happened, a reference containing a request id, and what to do next.
- Three events (start, success, error) are raised as bubbling DOM events and as optional callbacks. They carry a test id and a request id, never a value or a result.
Workarounds, and why they exist
- A data page can return normally and still report failure in a field. Without the result check the person would be told it worked.
- If the refresh fails after the data page succeeded, the message says so differently: “the request ran, but the page could not be refreshed”.
- With a single property as the parameter, the parameter name is read from the data page’s own definition, so the name lives in one place.
- The label can be typed text or a property reference such as .ButtonLabel. Anything that does not start with a dot is plain text, so an ordinary label is never mistaken for a property.
Your turn
Questions and comments
Stuck on something, or have a thought? Write it here. To talk about one part, use the Comment button under that section's heading.