What if Component App Classes Were Configurable?

With Fluid, PeopleSoft implemented an interesting design pattern: App Classes as Event Handlers. Properly implemented, there are some fantastic reasons to choose this pattern:

• Writing testable code (PSUnit)
• Code reuse

You can see Oracle's latest pattern on just about every Fluid component. A component that uses this pattern might have PreBuild PeopleCode that looks something like this:

import SOME_PACKAGE:SomeClass;
Component SOME_PACKAGE:SomeClass &handler;

&handler = create SOME_PACKAGE:SomeClass();
&handler.PreBuild();

But I had this idea... What if the code looked more like this:

import SOME_PACKAGE:SomeBaseClass;
Component SOME_PACKAGE:SomeBaseClass &handler;

Local string &className;

REM ** Select actual implementation of SomeBaseClass from a configuration table;
SQLExec("...", %Component, &className);

&handler = CreateObject(&className);
&handler.PreBuild();

Then we could override delivered behavior by subclassing and configuring our own handlers to override the delivered handlers. And I think this is the best reason to use App Classes as component event handlers. What would it take to implement this solution? Oracle would need to select the implementation class from SQL rather than hard-code its implementation into component PreBuild. But is it worth it? You know that is a fantastic question! You might say Event Mapping offers the same result but is more flexible. Let us know your thoughts in the comments!

At JSMpros, we teach PeopleTools and PeopleCode concepts like this regularly check out our website to see what we are offering next!