The following figure illustrates EGL compilation, which
is the process by which the EGL technology creates output from your
source code.
Details are in the following sections:
The developer’s task
The developer's
task is threefold: first, to write and test source code, which includes
the build step illustrated in the figure, although that step is typically
automatic; second, to generate and prepare the code for external deployment;
and third, to install the code on one or another platform.
Here
is an overview of the first two steps, which are specific to EGL technology:
- The EGL compiler is invoked as you are working on
a source file. The compiler acts as follows:
- Accepts the source code (file extension .egl).
- Validates the code for general syntax errors.
- Compiles the code into an intermediate representation of the logic.
When you save your file, the compiler also writes the output
to files. The compilation and output is called an EGL build,
and the output files are called an intermediate representation
(IR) file. In almost every case, the IR file is written even
if it includes errors.
The file extension for an IR file is eglxml.
- The EGL compiler invokes an EGL generator, which
acts as follows:
- Accepts the IR file, which must be error free.
- Scans the intermediate representation and determines whether a
generation is possible and valid.
This scan is called pre-generation.
It determines whether the IR fulfills the rules of the EGL target
system, which is the operating environment where the logic
ultimately runs; for example, a Windows platform.
- Generates output on the condition that no errors were found during
the pre-generation.
The generated output is JavaScript or Java™ (tm) source code.
- If generation succeeds, the generated output can become an input
to an EGL deployer, which readies the generated output
for deployment on an EGL target platform and places the completed
output in a web project.
You must explicitly invoke the deployer
by interacting with an EGL deployment descriptor. That
descriptor is a customizable XML file that controls aspects of service
and JavaScript deployment and includes details on how to access resources,
which are the services and databases that your logic requires. The
EGL deployment descriptor has the extension .egldd and
is different from the Java Platform,
Enterprise Edition (JEE) deployment descriptors.
As noted later, you might
need to add third-party jar files to the classpath of the server that
will receive your deployed application.
Uses of the EGL deployment descriptor
The
EGL deployment descriptor has two uses:
- To ready the generated output for deployment, as noted earlier.
- To provide the resource-access details that are used when you
are debugging or otherwise running code in the workbench.
The resource-access details that are used for deployment
are likely to be different from the equivalent details that are used
for running code in the workbench. To handle this issue, you can include
multiple EGL deployment descriptors in a given project. You make use
of one or the other with a few keystrokes:
- At any given time, you assign one descriptor as the development
deployment descriptor. This descriptor provides the details
that are needed to run your application in the workbench. For example,
the development deployment descriptor might point to a test database
rather than a production database and might reference an EGL Service
type that you are developing instead of referencing a deployed service.
To
assign a descriptor as the development deployment descriptor, you
right click the project, click Properties,
and update a list box.
- Similarly, when you deploy an application, you right click an
EGL deployment descriptor and click Deploy EGL Descriptor.
- At development or deployment time, you can ensure that the source
of a binding is a specific EGL deployment descriptor.
To specify
a particular descriptor, you code the descriptor name in either of
two locations:
- When you include the Resource annotation
in the statement that declares a binding variable, which
is the variable that makes possible the access of a service or database.
- Alternatively, when you use the Resources.getResource function
to assign a value to a binding variable.
When you create an EGL project, a single deployment descriptor
is included in the EGLSource folder, and the default behavior is for
that descriptor to be used as the development deployment descriptor
thereafter, even if you add new ones. One consequence is that, in
your initial work with EGL, you might not be concerned with the distinction
between the development deployment descriptor and others.
For
further details on working with the EGL deployment descriptor, see Editing an EGL deployment descriptor in the EDT IDE.
The stages of development
EGL
development involves several stages:
- You write the EGL source code at development time.
- The EGL compiler creates the output written to IR files at compilation
time. and an EGL generator creates the output that is specific
to an EGL target platform at generation time. The phrase transformation
time refers to compilation and generation time as a single
duration.
- The EGL deployer configures the output for an EGL target platform
at internal-deployment time.
- The deployable output might be re-configured for the specific
runtime environment at external-deployment time.
- The business application runs on the target platform at run
time.
Deploying third-party jar files
You
might need to add third-party jar files to the classpath of the server
that will receive your deployed application. Such files might include
JDBC driver jar files and, if you are accessing IBM i, the jt400.jar file.
You
can add a jar file in any of several ways. For example, during EGL
deployment, you might add the file to the lib folder
of the target project or as a library in the target EAR project. Outside
of EGL deployment, you might add the file as a resource in the server
classpath.