The Fields tab of the Entity Editor contains the information and editors for working with the fields of the entity, the unique constraints defined over these fields and the Fields mapped onto Related Fields. The different parts are contained in three horizontal sub-tabs which are described below.
The Entity Fields Tab
This sub-tab shows the fields defined in the entity. The fields are
shown in a grid, and directly editable. To add a new field, click in the
top-row of the grid or (when the grid already has focus) press
Ctrl-Shift-F to add a new field to the entity. You don't have to
specify all the columns, only the first two, Name and Type are
When you've specified enough information for the field, press
Ctrl-Enter to add the field. A new field will automatically get a
target field mapped, if the designer can find an unmapped field in the
mapped target element (if the entity is mapped to a target (table/view)
already) matching the newly added field.
Editing fields uses type shortcuts for specifying types easily. You
can type the first characters of the type shortcut to make the grid
automatically pre-select the type(s) matching the characters typed, like
TAB will move the focus to the next column. To
edit the Description, move to that column using
TAB or cursor keys and
Ctrl-DownArrow to open the small text editor to specify a
description for a field. Descriptions are generated as XML DOC comments
into the output.
To remove one or more fields, you have to select the fields using the row headers in the grid and click the Remove selected button at the bottom of the subtab.
To set the field order for the fields, click the Set Field Ordering button, which will bring up the Field Order Selector to specify the field ordering for the entity.
The designer supports refactoring of entity definitions by offering a small set of refactoring options for one or more selected fields. To perform a particular refactoring, select one or more fields to which the refactoring will be applied and click the Refactor selected... button at the bottom to select the refactoring from the list of available refactorings.
Not all refactorings are available at all times, only the ones which make sense for a particular situation: inheritance oriented refactorings aren't available when the entity isn't in an inheritance hierarchy.
The following refactoring options are available:
- Bounce Value Types in Selected to Local Fields
- This refactoring will for each field in the list of selected fields replace that field with all the fields of the Value Type Definition it has as its type. If a field has a .NET type, it's not refactored. This refactoring can be useful when you have set the type of a field to a Value Type Definition but now you rather want to have the fields of the Value Type Definition local to the entity. It's the opposite of the refactoring Convert Selected into Value Type.
- Convert Selected into Value Type
- This refactoring creates a new Value Type Definition (using the information you specify in the popup dialog shown) with the fields selected in the entity editor
and replaces all selected fields with a new field which type is set
to the just created Value Type Definition. Example: entity
Customerhas several fields which combined form an
Address. Select all those fields in the grid on the Entity Fields sub-tab and select the refactoring Convert Selected into Value Type. As name for the new value type, specify
AddressVt. This creates a new Value Type Definition
AddressVt, adds to it all the fields selected in
Customer, creates a new field into
Customer, of type
AddressVtand removes all selected fields from
Customer. The designer will also make sure the fields are properly mapped, if applicable.
- Move Selected to Subtype / Supertype
- This refactoring moves the selected fields to either the selected subtype or selected supertype, correcting mappings along the way.
- Replace selected fields with existing value type
This refactoring replaces the selected field(s) in the field editor with a matching existing Value Type. This refactoring is similar to Convert Selected into Value Type, however instead of creating a new Value Type, it uses an existing Value Type, if available. Which value types are offered through the refactoring menu depends on a couple of factors:
- The value type must be in the list of field types offered in the field editor. This is a safe way to filtering out value types which could lead to a cycle. As the field which will be a field like any other in the element and it will get the type of the valuetype chosen, it's equal to selecting a field's type through the list of available field types.
The value type must have the same number of fields selected and
the types must match, and if there are multiple fields with the
same type, the field names, lower case compare, must be equal.
Example: if there are two fields selected,
string, and there's a valuetype with two
f2, it is a match. This might be very strict, but it's otherwise a gamble: if there are two fields with the same type, it's not possible to replace them with fields inside a valuetype
This sub-tab allows you to define one or more unique constraints over the fields defined in the entity. In some target frameworks (e.g. LLBLGen Pro RTL) these unique constraints are used to create extra constructors / filter presets. They're also used to define unique constraints in the Relational Model Data, for the fields mapped by the entity fields in the unique constraints.
To define a unique constraint, click in the top row of the grid and
specify a valid name for the unique constraint. The second column is an
editor which opens in a separate dialog which allows you to select the
field(s) of the unique constraint. Press
Ctrl-Enter to add the row to
the grid, which adds the unique constraint to the entity definition.
It's not necessary to define a unique constraint for foreign key fields participating in a 1:1 relationship: LLBLGen Pro creates these unique constraints in the Relational Model Data automatically for you. Any unique constraint defined over the same fields is therefore redundant.
To remove a unique constraint from the list of unique constraints of an entity, simply select it and click the 'Remove selected' button at the bottom.
Fields mapped onto related fields is a feature which allows you to map a
field onto a related field (e.g. in the entity
Order the field
CompanyName in the related entity
Customer to a local field
CompanyName) in a related entity. These fields are not real entity
fields (they're not mapped onto an element in the target Table / View)
and can't participate in database queries; they're a feature which is
used in the code generator to produce properties in entity classes which
refer to fields in a related entity. This is useful in databinding
scenarios where an extra column is sometimes required in a list like
control, like a grid, though that column is data from a related entity.
Fields of entities which are related over m:1 or 1:1 relationships are
mappable as Fields mapped onto related fields. For example, an
entity has a related entity
Customer. To map the
field as a field in
Order, simply add it as a Field mapped onto
Related Fields in the Entity Editor for
Click the top row in the grid to add a new row and select the field to map from the combo box. Press
TAB to advance to the next column to see the field type and
specify the name of the field. Eventually select the checkbox for
ReadOnly and after that press
Ctrl-Enter to add the definition to the
To remove a Field mapped onto a related field, select it using the row header in the grid and click the Remove selected button at the bottom.