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.
Thanks for the code :). As a poor mans solution we at least (as Oracle does as well) use an HTML object to store the set of values in. That way we don't make typos as we stored it once correctly.
&sModalOptions = GetHTMLText(HTML.SCC_MO_POPUP_FL);
I was discussing creating just such a class with a colleague on Friday, so thanks for beating me to it and saving me some time!
One thing I've noticed is that some of the properties documents in PeopleBooks don't seem to work (eg sWidth and sHeight) and some aren't documented (eg bTail).
The lack of sWidth and sHeight is a real pain when you want a responsive modal - any thoughts?
@Dave, completely agree that they aren't documented well and may or may not work :). Unfortunately, I don't have a good suggestion for you. Please feel free to further enhance this code and submit pull requests. Likewise, this repo may be a good place to further document these properties, so please feel free to submit documentation pull requests as well.
Hi Jim - I am just learning people code oo coding but have many years experience programming oo in microsoft.net. In .net you would declare a mustoverride method or property in your base class that it would call and inheritors would then return the properties specific to them.
@Joe, in PeopleCode, I've seen two PeopleCode alternatives to mustoverride:
1. declare the method as abstract
2. throw an exception in the base method implementation
Post a Comment