Friday, January 25, 2019

Dialog and Popup Parameters

If you have implemented or reviewed Fluid self-service, you may have noticed all inline editable grids have been replaced with read-only "actionable" grids. Oracle's PeopleSoft Fluid UX Standards discourage the use of inline editable grids in favor of secondary modal popup pages. Sasank recently showed us how to implement actionable grid rows, the primary self-service replacement for inline editable grids. With the row action indicator approach, each row presents a read-only summary, with details and edit behavior rendered in a secondary modal popup page. Modal secondary pages are not new to Fluid, but are definitely more important with Fluid (since inline editable grids are now discouraged). This is a pattern we teach almost every week. Something that has always bugged me about PeopleSoft modal popups is the parameter string. Here is the example string from PeopleBooks:


Notice that these are two boolean properties with very specific names, allowing only 1 or 0 for values. So what is my problem? These properties and values are hidden from design-time compiler checking because they are wrapped in quotes. This offers no design time assurance. If we make a mistake, we won't know until runtime. Am I the only one that has spent hours debugging a typo hidden in a string? You know what I would like instead? I would like an object with strongly typed, named properties that I can set at design time. The compiler will see these properties and confirm that I am using them correctly. I decided to put one together and share it with the community. You can find the very simple code on our psdialogparams project GitHub repository. Feel free to download, change, submit pull requests, etc.

As you review the various parameters available to dialogs, popup menus, etc, you will notice similarities and differences. My intention was to place all similarities in a base class, but then allow implementation-specific subclasses (menus, dialogs, etc). Using inheritance I was able to place all common code (such as toString()) in the base class. But how is the base class to know what properties exist in the subclasses? Really good question that I'm not going to fully answer, but the basics are PeopleCode App Class reflection (thank you Integration Broker team).

To learn more about this topic or other PeopleTools-specific topics, please register for one of our PeopleTools classes. Do you have a group and want to host a custom training event? Review our course catalog and contact us for more details or to schedule.