Embedded

Embedded types are always created and used in the context of type of other kind. For example, let take a look at types like Address or Purchase line. Normally address is meaningless unless connected to a person or an organization. Purchase line type stores information about Item and Quantity in a context of purchase order or receipt. Without that context, the information like “Milk, 2 liters” does not convey much meaning by itself.

Normally when 2 composite types are associated by membership, i.e. type A has a field foo of type B, the foo is expected to connect a reference to object of type B but no other relationship between them is assumed to exist.  When object referenced by foo has to be modified, the editing is made in a separate form and not in the context of A type. The story with embedded types is different. Embedded types do not have identifier field. They behave as if they were integral part of the enclosing type that embeds them. When object of enclosing type is edited, the objects of its embedded types are edited at the same time. Fields of embedded types are available for event handling in the context of enclosing type. Embedded types can have views and their views are available for enclosing type too. When form view is created for enclosing type, the developer can choose the form view of embedded type and this view becomes part of the form of enclosing type. This feature can be useful for layout templates. If one needs a visual component, often it can be implemented once as an embedded type and used in different places. Nesting of embedded types is not allowed, i.e. embedded type cannot have other embedded types among its members.

Warning : Embedded data types can't contain collection fields and regular fields of embedded types.