| JPO Macros |
| Macro |
Meaning |
CLASSNAME |
Refers to the JPO name in the Java class definition.
|
CLASS:jpo_name |
Refers to other JPO classes inside the code
of a JPO, for example when extending a base class or newing up an object.
jpo_name is the name of the JPO holding the class of interest |
There are two problems with using schema object names for the JPO
class. The first problem is that schema object names are allowed to contain
spaces and other non-alpha characters that would cause errors in the
Java compiler. The second problem is dynamic changes to the schema object
names would not be automatically made to the code within JPOs.
Special macros are used to map the schema object names to legal Java-compliant
names (a process know as name mangling). These macros are also appropriately modified
automatically when a schema object name is changed.
Use of these parameterized class names allows both dynamic loading
of classes after the source has been changed without restarting the system
and automatic generation of dependencies between multiple Java Program
Objects.
For example, if there is JPO named "RADProject" and its corresponding
Business Type RADProject derives from Project, then the Java code defining
the class for RADProject would look something like:
public class ${CLASSNAME} extends ${CLASS:Project}{:}
During compilation, the macro ${CLASSNAME}
is mangled into a name that includes the JPO name "RADProject" (plus
a suffix of "_mxJPO" followed by a hashed encoding). The macro ${CLASS:Project}
is mangled into the exact same name as it was for ${CLASSNAME}
appearing in the Project JPO. In other words, the system does all the
appropriate name mangling and the JPO programmer needs to be concerned
only with the higher-level macros.
For example, the "Hello World" JPO ends up with a class name something
like "Hello_World_mxJPOtAXMTwEAAAAFAAAA" (the hashed encoding at the
end will vary).