sections in the article
This article gives a short overview of the essential concepts that are used in an elastic data model. The below sections all link to related articles that explain the concept more in depth.
For each data model, define a set of languages for which product information should be presented.
- Read more about languages in this article.
Server settings are a list of parameters that control specific behaviors in the system. inriver has a number of pre-built settings, but also includes options to create your own settings to configure extended functionality.
- Read more about server settings in this article.
Entities are the building blocks of a data model. Each EntityType defines an object in the model to which you attach a set of FieldTypes. Relationships are then defined between EntityTypes.
- Read more about EntityTypes in this article.
- Read more about entity icons in this article.
A Category is a mechanism to group similar field types. A category consists of a name and an ordering index and is mandatory for every field within an entity type. Using the combination of field and category indexing, it is possible to control the display order of both categories and their respective fields.
- Read more about categories in this article.
A FieldType is an object that carries an information element. FieldTypes have a number of properties describing how the data element will be behave. Examples of field properties include mandatory, read-only, and unique. Only a single FieldType can be assigned to one EntityType.
- Read more about FieldTypes in this article.
A Fieldset provides a way to control the display of fields within an entity. When assigning a Fieldset to an entity, you limit the number of fields that are visible to the user. This show/hide feature is useful when an entity contains a large number of fields.
- Read more about Fieldsets in this article.
A LinkType defines the relationship between two EntityTypes; one EntityType will be the Source and the other will be the Target. This can also be described as a Parent/Child relationship. It's also possible to link an entity to itself.
- Read more about LinkTypes in this article.
A Controlled Vocabulary List (CVL) is a special kind of data type that makes it possible to define a list of data points in the form of key/value pairs. CVLs are used primarily for data entry when you want to avoid the risk of spelling errors and invalid values. Instead, users must choose from a controlled list of predefined values. Examples include sets of colors, a list of brands, product groups, or status codes.
- Read more about CVLs in this article.
When you are creating objects in your Data Model, each field is assigned a unique FieldType identifier. These are String fields, and should describe the entity and FieldType they represent. There are restrictions on which characters you can use in these identifiers.
- Read more about identifier restrictions in this article.
There are some channel structure rules that you need to take into consideration. These rules are applied when the server is building up the channel structure, and when designing the your Data Model.
- Read more about channel structure considerations in this article.
When creating the FieldTypes that carry data elements, it is important to be familiar with the available inriver data types, defined below:
String is used for text values that are independent of language. This means that the text will always be displayed the same way, regardless of the language used. Examples include trademarks, product numbers, divisions, and so on.
The LocaleString data type makes it possible to store text in each of the languages defined in your Data Model. It must be used for all text fields that are language dependent.
A CVL data type requires the user to select from a predefined CVL. The CVL will provide values as Strings or LocaleStrings, depending on how it was defined when the CVL was created.
The boolean data type expresses values as either true or false.
Note! You have to make the FieldType mandatory to avoid having a "not set" option.
The DateTime data type represents date and time values in the form of month, day, year, hour, and minute.
The Integer data type represents whole numbers.
The Double data type represents numeric values that include a decimal point.
Using the XML data type means that values will be treated as xml and checked for validity.
File is a special data type reserved for the the resource EntityType.
the XML Field type is designed for structured data that does not need further enrichment, as the name suggests. It is not intended for converting XML files and storing as a data field.
A good example is SKU data in the fashion industry. The Product/Item describes the dress, it's pattern, material, marketing story etc. The sizes that the dress is available in can be stored as an XML Field, because there are many sizes but no further enrichment is required. You may want to store other non-editable information about the size, such as its EAN barcode number, and so it is not practical to use a CVL list.
Using in-context editing tabs, you can extract the XML data and present it in a user-friendly table format. You could potentially make this data editable in the tab and save it back to the Field as XML.
Although the Field-type is XML., you can store any format such as JSON and csv. Using XML makes the information compatible with Content Store, where there are configuration parameters to extract and present the data.
If possible could we get some more information on when to use XML Data Type, what are the benefits and cavities. For example when storing data from Extension, is it better to use XML field or resource binary when data content is medium to large file/binaries ?
Is there an option (or consideration of an option) for data type of just Date? I don't need the granularity of the time but want to ensure that a date is entered for a given field.
Please sign in to leave a comment.