Fields in Codejig Builder

Fields are blocks which composite data types are built from. Fields in Codejig Builder are quite similar to fields in Java or any other general purpose development environment. There are three kinds of fields in Codejig Builder: Regular fields, Collections and Dynamic fields. 

Any field could be marked as transient. Transient fields aren't stored in database and are mostly used to store and present to user temporary and calculated data.

Example: Imagine you have a dictionary data-type, called Order. It has two fields of Integer data type, called price and amount. And you'd like to add new field called total price. Its value is calculated as a product of amount and price, so there is no need to maintain its value in database. But this field is still required as we want to show this data to user. Solution is to make total price transient and use blocks to calculate its value.

Note:  Any field of transient type is a transient field. But not any transient field is a field of transient type.

Regular fields

Regular are the most basic part of composite data types. Regular fields are strongly typed, i.e. can contain only data of the specified type. Field type is defined during creation and can't be changed later. Regular field Regular fields could be either of value-type (primitives, embeddeds) or reference-type (all composite data types except embeddeds).  For more detais about data types, see a corresponding article. To understand the difference between value-types and reference-types consider the following example:

Example : 
Let E be an embedded data type with regular field f of type Integer, A - a directory data type with field d of type Integer, B - a directory data type with regular field e of type E and a of type A
Let z be an instance of A, x and y - instances of B.
Imagine we execute the following instructions:
z.d = 7
x.a = z, x.a = z
x.e.f = 7, y.e = x.e, y.e.f = 4 
a.z.d = 10
After execution, x.a.f equals y.a.f equals z.d and equals 10. As a is a field of reference type. But x.e.f not equal to y.e.f, as e is of embedded type, which is a value-type.

Collection fields

Collection fields of primitive and  journal data types are illegal.

Collection field of embedded  data type:

  • Behaves as value-type (as well as regular field of embedded type)
  • Is ordered. Order of items is defined by relativeOrder system shared field (see System defined shared fields for more details). The order can be changed either with code or with ui.
  • Its items an be modified in-place directly in owner's form. 

Collection field of any composite data type except embedded :

  • Is a collection of references.
  • Is unordered.
  • Its items can't be only added or removed, but not modified in-place. For modification we should use an update page of referenced instance.  

Collections of documentsdirectories and reports can be marked as virtual. Virtual collection is pretty similar to the collection you see on the type's index page. This collection always contains all instances of the specified data type, which are stored in the database. Basically, the content of all virtual collections of some fixed type is always the same. When you create/delete instance of this type it appears/disappears in all virtual collections of this type. This kind of collections is designed to develop custom index pages.

Note: You can't iterate through a virtual collection in code. Use stream of specified type instead. As virtual collection's content can be very large, it is lazy-loaded while user scrolls collection.

Note:  Collections of transient types are allowed. Transients have a row view but haven't form view (see Views for details), so that's the only way transient type can be displayed to the user.

Dynamic fields
Dynamic field is a reference to  document/directory/report instance. However, in opposite to regular fields, dynamics are not strongly typed, i.e. the exact type of it's content isn't known until runtime.

Example: Imagine you have two directories in your system Natural person and Legal Person. Both directories contain information about your clients. Now you'd like to create a document data type called Order with field client referencing specific client. What data-type should we use for this field? Obviously, we can't use neither Natural person, nor Legal Person. We need both. The solution is to use dynamic, which can contain both types of references.

Note: Often you'd like to filter data-types or instances which could be selected by user for a specific dynamic field. You can use on field filter and on field type filter events. See Field events for more details.