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

+

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.

−

EGL source files include EGL ''parts'', which are type definitions

+

−

that you create. For example, a Service part contains logic, and a

+

−

Record part can be the basis of a variable that you declare in your

+

−

Service part.

+

−

Packages are important because they separate parts

+

The EGL source files include EGL <span style="font-style: italic;">custom type</span>''s'', 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.

−

into different contexts, or ''namespaces'':

+

−

<ul><li>A part name might be duplicated in two different packages, and

+

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

−

any EGL source code can reference each part precisely. The main benefit

+

−

of namespaces is that different teams can develop different EGL parts

+

−

without causing name collisions.

+

−

<li>Each part name in a given package is unique within that package:

+

−

<ul><li>A part in one package can easily reference another part in the

+

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

−

same package by specifying the part name. For example, here is a declaration

+

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

−

of a record that is based on the Record part <tt>MyRecordPart</tt>:

+

**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{};

−

myRecord MyRecordPart{};

+

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

−

<li>A part in one package can also reference a part in a second package

+

−

by giving the package name and part name, or by a shortcut that involves

+

−

importing the part.

+

−

</ul>

+

−

</ul>

+

−

One project can reference the parts in a second project,

+

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.

−

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

+

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

−

task in this tutorial is to create the following projects:

+

−

<dl><dt>PaymentService

+

;PaymentService

−

<dd>Holds an EGL Service part and related definitions

+

:Holds an EGL Service type and related definitions

−

<dt>PaymentClient

+

;PaymentClient

−

<dd>Holds the Rich UI handlers and related definitions

+

:Holds the Rich UI Handler types and related definitions

−

<dt>PaymentShared

+

;PaymentShared

−

<dd>Holds parts used both on the Web client (the browser) by the handlers and on the Web application server by the EGL services.

+

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

−

</dl>

+

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.

−

You can include all your code in a single project,

+

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.

−

but the separation shown here lets you easily deploy the two kinds

+

−

of code in different ways.

+

−

Parts in one project can use parts

+

== Create the PaymentShared project ==

−

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:

−

To create the shared parts project:

+

#If you have been working with EGL in the current workspace, click '''File &gt; New''' '''&gt; EGL Project'''. If you have not been working with EGL, you might need to click '''File &gt; New''' '''&gt; Other''' and then expend '''EGL''' and click '''EGL Project'''. <br>

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.