Contents

Lesson 2: Set up the projects

An EGL application is organized in one or more projects, each of which is a physical folder in the workspace. A project contains an EGL source folder that is provided for you, and that folder contains one or more packages, which in turn contain EGL source files. This hierarchy is basic to your work in EGL: a project, then an EGL source folder, then a package with EGL source files.

The EGL source files include EGL custom types, which are type definitions that you create. For example, a Service type contains logic, and a Record type can be the basis of a variable that you declare in your Service type.

Packages are important because they separate types into different contexts, or namespaces:

A type name might be duplicated in two different packages, and any EGL source code can reference each type precisely. The main benefit of namespaces is that different teams can develop different EGL types without causing name collisions.

Each type name in a given package is unique within that package:

A type in one package can easily reference another type in the same package by specifying the type name. For example, here is a declaration of a record that is based on the Record type named MyRecordType: myRecord MyRecordType{};

A type in one package can also reference a type in a second package by giving the package name and type name, or by a shortcut that involves importing the type.

One project can reference the types in a second project, but only if the EGL build path of the referencing project identifies the referenced project. Again, this tutorial gives examples. However, in all cases, avoid using the same package name in different projects, as that usage can cause problems in name resolution.

Your next task in this tutorial is to create the following projects:

PaymentService

Holds an EGL Service type and related definitions

PaymentClient

Holds the Rich UI Handler types and related definitions

PaymentShared

Holds types used both on the Web client (the browser) by the handlers and on the Web application server by the EGL services.

You can include all your code in a single project, but the separation shown here lets you easily deploy the two kinds of code in different ways.

Types in one project can use types in a different project. EGL uses a build path to search for unresolved references. Later in this lesson, you will add the service project to the build path for the client project and the shared project to the build path for both the service and client projects.

Create the PaymentShared project

To create the project that contains shared types:

If you have been working with EGL in the current workspace, click File > New> EGL Project. If you have not been working with EGL, you might need to click File > New> Other and then expend EGL and click EGL Project.