Commenting JavaScript in PeopleTools

If we look at some of the HTML objects which store JavaScript in PeopleTools, we will find many styles of comments. Here are a few options.

Option 1
// Option 1 - Single Line Comment;

/*
Option 1 - Multi-line Comment 1;
Option 1 - Multi-line Comment 2;
*/

Option 2
//% Option 2 - Single Line Comment;

<!%
Option 2 - Multi-line Comment 1;
Option 2 - Multi-line Comment 2;
 -->

What is the benefit of using % meta-html?

The screenshot below shows how the javascript is rendered at runtime. We can see that using the % sign allows the meta-HTML processor to recognize the comments and delete them during runtime.

PeopleBooks: Comments in HTML

Does commenting style (% meta-html) really matter for JavaScript?

Not really. PeopleTools 8.53 introduced JavaScript Minification by default. The screenshot in the previous section was generated by disabling minification (using Signon - Page Generation trace settings). Therefore, the commenting style in JavaScript does not really matter if we don't override/disable the PeopleTools (8.53+) default minification which will delete all comments (regardless of style) in JavaScripts.

PeopleBooks: Working with JavaScript in HTML Definitions

Fluid UI | Deep-linking to a Fluid Homepage

When users login to PeopleSoft Fluid UI, they land on the system default Fluid homepage or the user personalized default Fluid homepage.

How can we override this default behavior and take users to a different homepage? First, why would we want to do that? There may be many reasons why we would need to deep-link to a specific Fluid homepage overriding the default behavior. For example, let us say we need to conditionally deep-link to a specific Fluid homepage from an external site using single sign on.

In Classic, we were able to simply pass a parameter (tab) to the homepage URL.

Default Classic Homepage

http://pi023.hcm92.com:8000/psp/ps/EMPLOYEE/HRMS/h/?tab=DEFAULT

Deep-link to Classic Homepage

http://pi023.hcm92.com:8000/psp/ps/EMPLOYEE/HRMS/h/?tab=HC_HRS_RECRUITING_HOMEPAGE_TAB

Deep-Linking to Fluid Homepage

Similar to the Classic Homepage parameter (tab), the Fluid Homepage allows us to pass a parameter (LP) to 'override' the landing page! Here is an example.

http://pi023.hcm92.com:8000/psc/ps/EMPLOYEE/HRMS/c/NUI_FRAMEWORK.PT_LANDINGPAGE.GBL?LP=HC_DEVELOPER_HOME_GBL

PeopleTools 8.56 Hidden Gem | HTMLAREA 'Respond Only Once' Property

While working on some quirks with reCAPTCHA implementation in a PeopleSoft PIA page, I stumbled on this scarcely documented, hidden gem in PeopleTools 8.56. For many years, we struggled with HTMLAREAs and how they behave with AJAX requests in PeopleSoft. Basically, HTMLAREAs get reloaded every time there is an AJAX request on the page which puts the responsibility on the developer to make sure any javascript code in the HTMLAREA continues to work as expected. Jim's post dating back to 2006 illustrates how long this has been a problem!

I ran into a similar problem with the reCAPTCHA implementation and I wrote additional javascript code to workaround the issue. In the process, I found this HTMLAREA page field property called 'Respond Only Once' which is new in PeopleTools 8.56. This property is not documented in PeopleBooks except for this one location as a related topic:
PeopleBooks - PeopleTools 8.56 - Field Class Properties

Based on what I found, this property when selected will exclude the HTMLAREA from AJAX requests. A total life saver! :)

Of course, the HTMLAREA will be included in the Save event (postback).

Demonstration of Problem

In this demo we can see how the reCAPTCHA plugin (as an example) which is generated by a HTMLAREA gets reloaded/refreshed on every AJAX requests. On the second server trip, the reCAPTCHA div will disappear because the reCAPTCHA API javascript is no longer loaded as expected.

HTMLAREA

Demo

We can see how the HTMLAREA is reloaded every server trip resulting the disappearance of the  reCAPTCHA plugin.

Respond Only Once Property

Let us set the 'Respond Only Once' property in the HTMLAREA.

Demo

In the following demo, we can see how the 'Respond Only Once' property helps to exclude the HTMLAREA from the AJAX requests and to avoid reloading its contents.

reCAPTCHA in PeopleSoft PIA Pages

In one of my previous blog posts, I showed how to implement reCAPTCHA 2.0 in PeopleSoft. My blog post only covered setting up the reCAPTCHA plugin on the PeopleSoft login page as a workaround for DOS, bot attacks, etc. I also mentioned that the effort to implement reCAPTCHA in a PeopleSoft PIA page (Classic/Fluid) should be very similar. But I found that there is one challenge with implementing the same client side code in the PIA (as noted by some comments in the post). The issue is a common problem we routinely run into when we combine a HTMLAREA (with JavaScript) and a PIA page! Every time there is an event that posts back to the server, the entire page is refreshed. Obviously and unfortunately for us, this will cause the HTMLAREA to reload as well. If there is javascript in the HTMLAREA and if we are referencing external scripts (as we do in reCAPTCHA), there is a risk that the script will be reloaded and any variables may be reset. In order to workaround this problem, we need to be extra careful with writing javascript in HTMLAREA making sure we properly 'manage' how our code is executed during such events. This is true for all cases not specific to this reCAPTCHA implementation.

To demonstrate the problem, I added the reCAPTCHA plugin (client side) code to a Classic PIA Page using a HTMLAREA.

Classic Page

HTMLAREA and Page Activate PeopleCode

The HTMLAREA is populated dynamically using Page Activate PeopleCode.

JavaScript and HTML for reCAPTCHA

The javascript and HTML needed to display the reCAPTCHA plugin is stored in a HTML object (CSK_RECAPTCHA).

Result

We can see that the reCAPTCHA plugin is displayed successfully on the page.

Demonstration of Problem

Basically, on the second postback the reCAPTCHA API javascript will no longer load and therefore result in the reCAPTCHA div to disappear. In the demo, we can see the problem occurs during the FieldChange (Server Trip) and the Save events.

Solution

To solve this problem, instead of directly using the script element in the HTMLAREA to reference the reCAPTCHA API javascript, I wrote a javascript function to load the script in the DOM.

Result

reCAPTCHA Callback Function

You may notice that there is another function called svRecaptchaCallback and it is used as the data-callback attribute value in the reCAPTCHA div element. This callback function is a great feature that is available with reCAPTCHA which allows us to execute our custom code upon a successful reCAPTCHA event. You can see in the following demo that the message is printed on the console once we complete a successful reCAPTCHA verification. As an example, this could be used to conditionally activate/display certain page field elements only after a successful reCAPTCHA verification. Please note that this is purely on the client side. That is, the callback function is available and executed on the browser as part of our HTMLAREA. This is not the same as the server-side validation!

Notes

- Environment Details: HCM 9.2 PUM Image 23, PeopleTools 8.56.01.
- The main focus of this post is the client-side implementation. The server side validation logic can be implemented based on the code provided in my previous post. Only difference here is that we will be executing the PeopleCode in a event such as SavePreChange or similar instead of the SignOn PeopleCode event.
- The implementation in this post is done as a proof of concept only. When implementing reCAPTCHA in a PIA page, we may also want to consider only prompting the user with the reCAPTCHA validation once. Prompting the users to confirm that they are not robots on every Save event might not result in a great user experience.

Sample Project on GitHub

https://github.com/SasankVemana/reCAPTCHA-in-PIA