PeopleSoft Reconnect Live 2026 at Blueprint 4D!

Looking for the premier opportunity to connect with PeopleSoft customers and dive deep into PeopleSoft's product strategy? Join us at PeopleSoft RECONNECT Live, part of Blueprint 4D! With the conference just a few weeks away, we're excited to unveil our session lineup:

• Session - P-052187: What's New in 8.62 for Campus Solutions
  Monday, May 4, 2026, 3:45 pm CT | Room: Miro
  Discover the latest updates in 8.62, with a special focus on PeopleTools Landing Pages for Campus Solutions. Whether or not you're a Campus Solutions customer, this session is packed with insights for anyone interested in PeopleTools.
• Session - P-052181: Getting the Most out of PeopleSoft PeopleTools—Tips and Techniques
  Tuesday, May 5, 2026, 9:00 am CT | Room: Topaz
  Explore practical tips for using PeopleSoft PeopleTools, including Fluid, Integration, and Java. Take advantage of this opportunity to discover innovative ways to expand your PeopleSoft toolkit.
• Session - P-052189: Enterprise Components—The "Other" Toolset
  Thursday, May 7, 2026, 9:00 am CT | Room: Metropolitan
  Learn about valuable tools available to PeopleSoft developers beyond the standard PeopleTools suite. We'll discuss how to access these tools, best practices for using them, and why different applications may offer different versions.
• Session - P-052186: Replacing Customizations with Configurations in Campus Solutions
  Thursday, May 7, 2026, 11:00 am CT | Room: Madrid
  Event Mapping, Drop Zones, and Page and Field Configurator are important tools for Campus Solutions, but there is a twist! Join Jim Marion on Thursday to learn techniques to help you build more robust, maintainable solutions.

We are ready to connect and collaborate. See you in Dallas!

Fluid, Classic, or Classic Plus?

Let's say you are going to build a brand new component in PeopleSoft Application Designer. Would you build it using

• Classic,
• Classic Plus, or
• Fluid?

Here is how our LinkedIn audience answered that question:

Why Fluid?

Over 50% of our audience chose Fluid, and here are some reasons:

Strategic Direction

Fluid is Oracle's strategic direction. This means everything new that Oracle builds will be built in Fluid. If Fluid is Oracle's strategic direction, perhaps it should be ours as well?

Accessibility

Fluid generates better markup for screen readers and other accessibility features. If you must comply with the New Rule on the Accessibility of Web Content, then Fluid is your best option.

Mobile and Touch Friendly

Fluid is touch-friendly out of the box. Data entry fields have more space around them, and buttons are larger to facilitate touch. Through adaptive style classes and adaptive PeopleCode, Fluid can render better on mobile, whereas Classic renders the same across all devices.

Styling and Layout

Fluid offers more flexibility than Classic through grid types, HTML elements, and the PeopleCode function AddStylesheet.

Is Classic Still Relevant?

With so many good reasons to choose Fluid, is there still a case for Classic? We believe the answer is, "YES!" Many PeopleSoft-delivered business processes are 100% Classic. If you are extending an Oracle-delivered business process with a new component, it might make sense to build that component in Classic. Otherwise, your new component would be the only Fluid component in the business process. Another reason to choose Classic is that you prefer Classic features, such as highly flexible Related Content at the bottom of the page or traditional Scroll Areas.

Where Does Classic Plus Fit?

Classic Plus is Classic with a different skin. All Classic features apply to Classic Plus. Development for Classic Plus is nearly identical to Classic. Since Classic Plus requires more area, the only development consideration is spacing: Is there enough room?

Classic Plus makes Classic content look like Fluid, but not behave like Fluid. It just changes the PeopleSoft theme to look like Fluid. Classic Plus is a great way to make your existing Classic pages merge with a new PeopleSoft-delivered Fuid experience. Alternatively, Classic Plus is a great way to make PeopleSoft's Classic content merge with your new Fluid content.

So what do you think? As you consider new components, will you create them in Classic, Classic Plus, or Fluid?

At JSMpros, we teach PeopleTools tips like this daily! Check out our live virtual events calendar to schedule your next class. Interested in learning more about Fluid specifically? Then be sure to check out our Fluid-specific collection!

All of our classes are available live, live virtual, and on-demand. Want to learn more? Contact us, and let's get you scheduled!

Is GenerateComponentPortalURL Still Relevant?

Let's say you need to link from one PeopleSoft component to another. How would you generate the link? Perhaps FieldChange PeopleCode on a button or hyperlink? If so, what PeopleCode function would you use? GenerateComponentPortalUrl? PeopleCode includes functions such as GenerateComponentPortalUrl for generating URLs. But are these functions the best approach?

The URL generation functions create a URL to any menu/component combination. Provide these functions with PeopleTools metadata, and they will craft a URL. But here is the problem:

They have no regard for the Portal Registry.

Many Oracle-delivered Fluid solutions use framework components, such as PT_AGSTARTPAGE_NUI (Activity Guides and Navigation Collections) and PT_FLDASHBOARD (Dashboards). These framework components use Query String attributes, such as CONTEXTIDPARAMS. With Framework components, it is not enough to just create a menu/component/market URL with a function like GenerateComponentPortalURL. We must also consider the additional Portal Registry attributes.

Here is an alternative: Use the Portal Registry API. Instead of using GenerateComponentPortalURL, leverage the Portal Registry metadata. Here is a PeopleCode fragment to get you started:

method getCrefAbsoluteContentUrl
   /+ &crefId as String +/
   /+ Returns String +/
   Local ApiObject &PTPortal = %Session.GetPortalRegistry();
   Local ApiObject &CREF;
   
   If &PTPortal.Open(%Portal) Then
      &CREF = &PTPortal.FindCRefByName(&crefId);
      &PTPortal.close();
      Return &CREF.AbsoluteContentURL;
   Else
      Return "";
   End-If;
end-method;

I would place this code in a common, reusable container for future use. Now, what do you think, should we put this code in an Application Class or a Function Library?

Use generation functions, such as GenerateComponentPortalUrl, when you don't have a Content Reference. Otherwise, consider using the Portal Registry.

At JSMpros, we teach PeopleCode tips every week! Check out our live virtual events calendar to schedule your next class. Interested in learning more about PeopleCode specifically? Then check out these two classes:

• PeopleCode
• PeopleCode Application Classes

Both are available live, live virtual, and on-demand. Want to learn more? Contact us, and let's get you scheduled!

App Classes Versus Function Libraries

If you were to create a reusable code fragment, would you use an App Class or a Function Library? We asked our LinkedIn audience, and this was the result:

Do these results surprise you? Here are some insightful comments from the poll participants:

"Application Classes... For so many reasons:

1. Application Classes hold state across method calls
2. You get maintenance savings from classes
3. Application Packages can bundle related code
4. Classes give you public, protected, and private methods
5. Encapsulation and state
6. Clear Namespaces"

"I have always preferred application classes over function libraries because I find the discoverability of functions to be severely lacking. They can be placed just anywhere in any field in any record. And I can never remember the format for the declare statement."

"Don't forget about the variable declarations and type checking, which can avoid lots of problems at Runtime. That is on top of a clear inventory of available methods at the top of the class."

"Hands down application class..."

"My personal problems with functions:

1. Keep forgetting library records 
2. Can’t group code without creating a new library
3. Can't use them for configuration such as IB Handlers"

"I haven't willingly created a new function library in years.

• Application classes are much neater
• Nicer to implement
• Like the OO[P] reference
• Not nested in other code"

"A bonus of using Application Classes is being able to test any of your code from a delivered component in the PIA with the Application Class Tester. Navigation: Enterprise Components > Component Configurations > Application Class Tester. One of the best development tools that Peoplesoft delivers!"

Let's do a side-by-side comparison of the differences identified in the comments:

	App Classes	Function Libraries
All variables must be declared	✓
Stateful	✓
Testability	✓
PeopleCode-specific container	✓
Dynamic execution	✓
Object-oriented concepts such as Inheritance and Composition	✓
May be used by frameworks (IB, etc.)	✓
Stateless		✓

While the App Class column has the most checkmarks, is it the right answer for every situation?

All Variables Must Be Declared

Function libraries allow us to use variables without declaring them. An undeclared variable becomes implicitly declared as a generic data type upon first use. The problem with implicitly defined variables is that they support typos. It is really easy to mistype a variable name, which then becomes a new implicitly defined variable.

Application Classes will not compile and save unless you declare every variable. This avoids implicit typos.

At JSMpros, we teach that all variables should be defined at all times. The compilation output window, therefore, becomes a worklist. If a variable appears in the list, either declare or fix it. At the end of the day, anything in the list is a typo.

State

Application Classes are stateful, whereas Function Libraries are stateless. Both have their place. Application Classes must be instantiated prior to use. There are times when I have a code fragment that doesn't require state. Instantiating an object to perform a stateless operation seems like a waste. If the logic does not require state, then Application Classes may be overkill.

Testability

With Oracle-delivered solutions, such as the Application Class Tester, and community projects, such as PSUnit, it may seem that Application Classes are easier to test. But testability has more to do with coding practices than the container. For example, code you plan to test should avoid context-aware functions and variables. Whether you are testing App Classes or PeopleCode functions, you will write test case PeopleCode, which can be as simple as an App Designer-run App Engine.

PeopleCode-specific Container

Function Libraries are PeopleCode functions attached to events in Record Field PeopleCode. This can be challenging to manage. Having a PeopleCode-specific Container, such as an App Class makes a lot of sense. I do wish Function Libraries were stored in their own container. This doesn't impact their functionality, but it does affect lifecycle management and reuse.

Dynamic Execution

As noted in the comments, function libraries must be declared before they are invoked. We could argue that Application Classes have the same requirement in the form of import statements, but that's not exactly the case. One of the most powerful features of Application Classes is that we can instantiate objects, invoke methods, and set properties at runtime without knowing the implementing class at design time. We do this through the PeopleCode functions CreateObject, ObjectDoMethod, and ObjectSetProperty. These three functions allow for fully dynamic PeopleCode. In short, Application Classes don't need to be declared. It is this characteristic that allows PeopleSoft to build frameworks, such as Approval Workflow Engine, Event Mapping, and Integration Broker.

Object-Oriented Concepts Such as Inheritance and Composition

This is a key component to making Dynamic Execution work. We can create frameworks that code to interfaces and abstract base classes, and then use dynamic functions to instantiate full implementations at runtime.

Overall, object-oriented programming is not considered better or worse; it's just different. Poorly designed inheritance hierarchies can cause more problems than they fix. Perhaps what makes them challenging is that a solution is not static. We might create an amazing hierarchical design for the first build, but over time, that design becomes corrupted through changes. Composition is an Object-oriented concept that attempts to overcome the challenges of Inheritance.

May be used by frameworks (IB, etc.)

This feature brought to you by Dynamic Execution. Because we can code to an interface, we don't need implementation details until runtime. This makes App Classes perfect for AWE, IB, Event Mapping, PSUnit, Landing Pages, and much more!

In conclusion, each strategy has its place. Choose Function Libraries in the following situations:

• There are times when you must use Function Libraries. Signon PeopleCode is a great example.
• I also choose Function Libraries for stateless routines. If your reusable code fragment is stateless, then the overhead of App Classes may be overkill.

Choose App Classes:

• If you are building a framework, such as AWE, and want to register future event handlers, Application Classes are the right tool. You, the framework builder, would code to an interface, and later implementations provide the runtime details.

Which do you prefer? Let us know in the comments.

We teach both topics in our on-demand PeopleCode course. Already familiar with Function Libraries and want more information on Application Classes? Enroll in our on-demand course or join us for our next live virtual session!