| 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).