Introduction

This document describes the Enfinity Definition Language (EDL).

References

• Application Programming Guide: see Intershop Studio | Help | Help Contents | Intershop Studio Application Programming Guide
• Concept - EDL Modeling
• Cookbook - EDL Modeling

Core Language

Comments

EDL defines 3 types of comments: single-line comments, multi-line comments and parser-agnostic comments.

// This is a single line comment. It ends with the line break.

/**
 * This is a multi-line comment. It should be written using the typical Java syntax.
 */

/##
 # This is a parser-agnostic comment. It can be contained in an EDL file, but will
 # be ignored by the parser, so it will not be contained in the resulting EDL model
 # and cannot be processed further.
 #/

Any language element can have an associated description, which is reflected by a multi-line comment in front of it.

Imports

All references to types that are defined in a different EDL file must be explicitly declared using an import statement. The import consists of a URI to the EDL file containing the wished type. The URI points to a file, not a model element, so it must include the full path to the file and the file ending.

import "enfinity:/core/src/com/intershop/SomeEDLFile.edl";

Primitive Types

All primitive types that are used in an EDL model must be declared. There are no built-in primitive types in the language itself.

primitive boolean;
primitive int;
primitive string;

Basically, any primitive type can be declared. However, there are restrictions which primitive types the JGen code generator actually understands and is able to handle. Refer to the JGen documentation for details. The Core cartridge comes with some often-needed types that are supported by the JGen code generator. This file can be imported into own EDL models, so it is not necessary to declare the same primitive types again and again (though it would work, too).

import "enfinity:/core/edl/com/intershop/beehive/core/types.edl";

External Types

External types represent types that are used in EDL, but are not fully defined in EDL. They form an alias for an existing Java type, so that the type can be used in the model.

external Collection type "java.util.Collection";

Namespaces

A namespace can be compared with a Java package. It groups complex types into logical units. Namespaces can be nested. Alternatively, the name of the namespace can reflect the nesting by using a Java-like syntax. An EDL file can contain multiple namespaces.

namespace com
{
    namespace intershop
    {
    }
}

namespace com.intershop
{
    // this is equivalent
}

Primitive and external types have no namespace, so they must be declared outside of the namespaces (e.g. in front of them). On the other hand, complex types such as ORM classes always must have a namespace, so they can only be declared within a namespace.

Namespace Types

Namespaces contain the definitions of complex types. Currently, EDL supports ORM types, CAPI types, RAPI types and XML types.
All complex types in the EDL language follow roughly the same language structure. Which features are available for each type, depends on the specific sublanguage for the type (see later this document). Usually, they consist of:

• modifiers
• constraints
• properties
• attributes
• relations
• dependencies
• operations

Modifiers

A modifier is a single keyword that specifies the behavior of a complex type, attribute or relationship. It can be placed in front of the element (e.g. "abstract"), or behind the element. Which modifiers are supported depends on the sublanguage. Typical modifiers are:

• "abstract" for classes
• "readonly", "required", "localized" for attributes
• "pageable" for relationships

Constraints

Some complex types or members (ORM relationships, dependencies) can have a body with additional constraints. A body is contained within brackets ("{" and "}"). The constraint provides additional definitions that refer on the members of the element. Examples:

• primary key(...);
• alternate key(...);
• foreign key(...) -> (...);
• unique index(...);

Properties

A property consists of a single keyword and a value, which is usually a literal, or sometimes a pre-defined keyword. It can be placed behind the element definition. Properties and modifiers can be mixed. Which properties are supported depends on the sublanguage. Typical properties are:

• extends SomeSuperClass
• implements SomeSuperInterface1, SomeSuperInterface2
• table "..."
• column "..."
• cached soft

Attributes

An attribute is a member that has a name, a type, and some sublanguage-specific additional features. The type of an attribute is usually a primitive type, or an external type.

Relations

A relation is a member whose type is another complex type. Depending on the sublanguage, different features of relationships are supported.

Dependencies

A dependency is a special kind of relation.

Operations

Operations are methods of a complex type. Usually, they take parameters, have a return type and may throw some exception.

Literals

There are a number of literals that can be used in EDL, e.g. for expressing default values or other values. Currently, EDL supports:

• float literals (a floating point number)
• integer literals
• string literals ("...")
• boolean literals (true or false)
• null literal (null).

Reserved Keywords

EDL comes with a number of reserved keywords that cannot be used as identifiers for classes, members and so on. If such an identifier collides with an existing keyword, the identifier must be escaped. Xtext supports the ^ character for this, e.g. the identifier must get ^ as prefix.
Example:

namespace com.intershop.^orm
{
}

Here is the list of the reserved keywords:

back to TOC

ORM Types

ORM Classes

An ORM class describes a type for the ORM object-relational-mapping layer of Enfinity. Its Java implementation can be generated by JGen.

An ORM class must be defined within a namespace.

ORM Attributes

An ORM attribute is a member of an ORM class.

The type of an ORM attribute can either be a primitive or an external type.
The optional length of the attribute defines the length of the underlying database column. It must be an integer. If not specified, the default length of the code generator applies.
The attribute can have a default value, which is given as a literal.

ORM Relations

An ORM relation is a member of an ORM class.

An ORM relation always points to an ORM class, e.g. the type is an ORM class. Its cardinality can be one of 0..1, 1..1 or 0..n.

ORM Dependencies

ORM dependencies represent so-called weak relations for ORM classes. The type of an ORM dependency can either be an ORM class, or a CAPI interface. Currently, there are no modifiers. The cardinality is always 0..1.

ORM Example

Here is a small example for the definition of two ORM classes in EDL:

primitive uuid;
primitive string;

namespace com.intershop.example
{
    abstract orm class BusinessObject oca timestamp
    {
        primary key(UUID);
        unique index(name);

        attribute UUID : uuid;
        attribute name: string<256> type "CLOB" required;
    }

    orm class Product extends BusinessObject table "PRODUCT_TABLE"
    {
        attribute bundleID : uuid;

        relation bundledProducts : Product[0..n] inverse productBundle
        {
            foreign key (bundleID) -> (UUID);
        }

        relation productBundle : Product[0..1] inverse bundledProducts;
    }
}

back to TOC

CAPI Types

CAPI Interfaces

The CAPI models define the Enfinity cartridge API (CAPI). Typically, this is just a thin interface layer that is implemented by ORM classes or other Java classes.
Members can be CAPI attributes, constants, relations or operations.

CAPI Attributes

A CAPI Attribute is a member of a CAPI interface. The type of a CAPI attribute can be a primitive type or an external type. The optional dimension defines the dimensions for arrays of the type. For each dimension, a pair of brackets must be specified, e.g., [][] stands for a two-dimensional array.

CAPI Constants

A CAPI constant is a member of a CAPI interface. It defines a public static final attribute. The type can be a primitive type or an external type. The value must be provided as a literal.

CAPI Relations

A CAPI relation is a member of a CAPI interface. The type of the relation must be another CAPI interface. The cardinality can be 0..n or 0..1.

CAPI Operations

A CAPI operation is a member of a CAPI interface. The parameter types and the return type of an operation can be a primitive type, a CAPI interface or an external type.
The optional dimension defines the dimensions for arrays of the parameter or return type. For each dimension, a pair of brackets must be specified, e.g., [][] stands for a two-dimensional array.

CAPI Example

Here is a small example for the definition of CAPI types in EDL:

primitive float;
primitive string;
primitive uuid;

external IllegalArgumentException type "java.lang.IllegalArgumentException";

namespace com.intershop.example
{
    cartridge interface Product
    {
        attribute UUID : uuid readonly;
        operation getPrice(currency: string) : float throws IllegalArgumentException;
    }
}

back to TOC

XML Types

XML Classes

XML classes define Java data structures that can be converted into / from an XML representation by a generated encoder / decoder. An XML class can be a value type, or an object type, depending on its inheritance from the DValue or DObject superclasses (see JGen documentation).
The members can be XML attributes or XML containments.

XML Attributes

An XML attribute is a member of an XML class. The type can be a primitive type or an external type. The optional dimension defines the dimensions for arrays of the attribute type. For each dimension, a pair of brackets must be specified, e.g. [][] stands for a two-dimensional array. The default value can be a literal.

XML Containments

An XML containment is a member of an XML class that represents a sub-tree in an XML document. The type must be an XML class. The cardinality can be 0..1 or 0..n.

XML Example

import "enfinity:/core/src/com/intershop/core/foundation/common/DObject.edl";

primitive string;

namespace com.intershop.example
{
    xml class DProduct extends DObject
    {
        attribute name : string tag "product-name" type element;
        containment bundledProducts : DProduct[0..n] tag "bundled-products" type text;
    }
}

back to TOC

RAPI Types

RAPI Interfaces

The RAPI model defines the Enfinity remote API. It consists of RAPI interfaces that represent a single remote service each. Members can be RAPI operations.

RAPI Operations

RAPI operations represent method declarations for remote interfaces. The parameter types and the return type of an operation can be a primitive type, an XML type, a CAPI interface or an external type. The optional dimension defines the dimensions for arrays of the parameters or the return type. For each dimension, a pair of brackets must be specified, e.g. [][] stands for a two-dimensional array.

back to TOC