Quite a few of the classes handle things like page layout and validation, things we definitely wanted to modify. They even delivered a lot of "factory" like classes that their code calls and all it does is return an object of a certain type. It seemed like a perfect setup for being able to customize the look and feel and behavior by simply supplying custom application classes. However, the implementation classes are hardcoded in the factory methods. So while there is a way to substitute the implementation of a certain class it still requires a modification to delivered code.
The Approvals Framework, on the other hand, is a perfect example of how application classes should be used. It is completely built around the concepts of dynamically loading classes at runtime based on values entered in setup tables. No code modifications are required, you just create your class and enter the fully qualified name in a setup table. The framework looks up the class you specify, loads it up dynamically at runtime and then calls the methods on it.
An example (code changed to protect the innocent):
class MyEventHandler extends BaseEventHandler
method onApprove();
method onDeny();
...
...
end-class;
...
The framework can then lookup the class name in a setup table and call the methods it provides. It knows what methods it can call based on the fact that my class must extend a class they know about (BaseEventHandler).
Local string &clazz = /* sql lookup here */;
Local BaseEventHandler &object;
&object = CreateObject(&clazz) as BaseEventHandler;
&object.onApprove();
PeopleSoft, which knows nothing about my custom class, is able to load it up and use it. This is a very powerful and elegant way to provide custom functionality without requiring anything more than an entry in a setup table. Unfortunately, I haven't yet seen many places where this type of extensibility is used in PeopleSoft 8.9.
4 comments:
Very good post John. PeopleSoft's Portal team uses the same technique to apply branding. You can see PeopleSoft's code in function CreateBrandingObject in the record field PeopleCode WEBLIB_PORTAL.PORTAL_HEADER.FieldFormula.
In our environment modifications to delivered objects is strongly discouraged and can involve a mass of red tape. We do have some leeway with self service related components and are freely able to create projects that contain new objects that are prefixed accordingly.
What would make my day is to have the component processor have hooks that you could register in a setup table. For example, if there was a delivered BasePeopleEvent app class delivered that I could extend or implement to either override or extend the HRS_CE.GBL.HRS_CE_LNK_WRK
.HRS_SAVE_BTN.FieldChange. That way I would never have to touch delivered code.
I've heard at past conferences that Oracle is working on separating custom mods from what's delivered, I can't wait to see what they come up with.
Ah yes... I work primarily in Enterprise Portal. One of the things that I like about Enterprise Portal is that it actually does store the branding app class I previously mentioned in a table. To override the delivered app class with your own, you just have to change the value at PeopleTools > Utilities > Administration > PeopleTools Options.
I've worked with HCM 8.9 TAM modules and I also see most of the implementation classes being hard-coded.
CRM 8.9 though makes extensive use of setup tables for specifying "Application Extensions", where the concept you've discussed here is used.
Post a Comment