Insatiable Application Classes

By Larry Grey • September 25, 2007


While double-checking something in PeopleBooks about Application Classes, I came across this typo.

Generic base classes contain reusable logic for PeopleCode classes; you write them to be self-contained, fully implemented, and insatiable.

I believe that instantiable was the word they were looking for. Heh. Spell-checkers can’t save you from those errors.

In case you care, what I was looking for was a way to make the constructor for a base class only available to subclasses. The base class provides a bunch of functionality without applying any specific security rules. The subclasses fill in the security details for their specific requirements.

App Designer will let you save the constructor as protected, but it actually makes the constructor public at runtime. Good thing I tested that 🙂

PeopleBooks does say that what I want to do is not allowed (constructors have to be public), which is unfortunate. The workaround is to have a separate “validate” method that sets an internal flag once called. The base class version throws whatever error you want to give, and the subclass version(s) perform the proper checking. That adds extra complexity to the methods in the base class though since they need to check the internal flag at the beginning of each method before doing their “real” work.

The alternative would be to just put a few comments in the base class code saying “Please don’t use this class directly as it can be a security problem”. Everyone reads comments in the code before using it though, right? 🙂


Stay Updated

Request a Demo