# Content Motation

## What is Content Motation? <a href="#motation-types" id="motation-types"></a>

Content Motation is the primary Motation object created and used. Every Motation will have a content Motation object. A content Motation then has dependencies that are other Motation objects which provide the definition, relationships, etc. which are synced prior to the content Motation being synced.&#x20;

Thus every source connector will generate a content Motation and every destination connector will support a minimum content Motation. But not every source connector will generate the other Motation objects. Nor will every destination connector support the other Motation objects.&#x20;

## Motation Types <a href="#motation-types" id="motation-types"></a>

Every Motation will have a type. There are only two Motation types possible.&#x20;

<table><thead><tr><th width="194.78735368156003">Motation Type</th><th>Description</th></tr></thead><tbody><tr><td>Content</td><td>The default Motation type. This is used for most data picked up from a repository. If a repository has additional types of data, they should be handled with repository specific attributes and listed as a supported repository. </td></tr><tr><td>File</td><td>A Motation file type <strong>requires a binary field</strong>. In addition each destination connector will be able to handle a file type differently than a content type. Otherwise, a Motation file type is not very different than a content type. </td></tr></tbody></table>

Each Motation type supports all Motation fields. However there may be additional restrictions for certain types (i.e., File type requires a binary field). In addition, a Motation type should be selected appropriately with correct intention for the data. This is because destination connectors are expected to be able to use the Motation type to handle specific types in the repository.&#x20;

## Motation Fields

Each Content Motation object has a field. These fields all have a type that matches the associated Definition Motation object's type. The Motation has the following field types.&#x20;

<table><thead><tr><th width="188.38136187940694">Field Type</th><th>Expected Value</th><th>String Name</th><th data-hidden></th></tr></thead><tbody><tr><td>Array</td><td>An array value. Values are not selectable. </td><td>Array</td><td></td></tr><tr><td>Big Integer</td><td>A big integer value.</td><td>BigInteger</td><td></td></tr><tr><td>Big String</td><td>A Big string value. </td><td>BigString</td><td></td></tr><tr><td>Binary</td><td>A binary value. <code>binary</code> attributes will be populated. The <a href="https://motivlabs.gitbook.io/impulse-dev-manual/motation/content-motation#structure">structure</a> section below details these attributes.</td><td>Binary</td><td></td></tr><tr><td>Boolean</td><td>A boolean value.</td><td>Boolean</td><td></td></tr><tr><td>Category</td><td>The IDs of the category objects.</td><td>Category</td><td></td></tr><tr><td>Checkbox</td><td>A checkbox value. Often an array of "tickable" values</td><td>Checkbox</td><td></td></tr><tr><td>Date</td><td><p>A date value. </p><p>Format of value is <code>yyyy-MM-dd'T'</code>.</p><p>"Zero" value is <code>0001-01-01</code></p></td><td>Date</td><td></td></tr><tr><td>Date-Time</td><td><p>A date and/or time value. </p><p>Format of value is <code>yyyy-MM-dd'T'HH:mm:ss.SSS'Z'</code>.</p><p>"Zero" value is <code>0001-01-01 00:00:00 +0000</code></p><p>Meaning, if using only date value, time value will be <code>00:00:00 +0000</code> . While if using only time value, date value will be <code>0001-01-0</code>. </p></td><td>Datetime</td><td></td></tr><tr><td>Decimal</td><td>A decimal value.</td><td>Decimal</td><td></td></tr><tr><td>File</td><td>A type of relationship. Use ID of a file content. <code>Relation</code> attributes will be populated. The <a href="https://motivlabs.gitbook.io/impulse-dev-manual/motation/content-motation#structure">structure</a> section below details these attributes.</td><td>File</td><td></td></tr><tr><td>Float</td><td>A float value.</td><td>Float</td><td></td></tr><tr><td>Image</td><td>The ID of an image binary file.  </td><td>Image</td><td></td></tr><tr><td>Integer</td><td>An integer value.</td><td>Integer</td><td></td></tr><tr><td>JSON</td><td>A JSON value. Requires JSON conformity. </td><td>JSON</td><td></td></tr><tr><td>Key Value</td><td>A key/value pair value. </td><td>KeyValue</td><td></td></tr><tr><td>Multi-select</td><td>A multi-select value. An array with multiple options selectable.</td><td>Multiselect</td><td></td></tr><tr><td>Radio</td><td>A radio value. An array with only one option selectable at a time. </td><td>Radio</td><td></td></tr><tr><td>Relationship</td><td>A relationship value. <code>Relation</code> attributes will be populated. The <a href="https://motivlabs.gitbook.io/impulse-dev-manual/motation/content-motation#structure">structure</a> section below details these attributes.</td><td>Relationship</td><td></td></tr><tr><td>Select</td><td>A select value. An array with only one option selectable at a time.</td><td>Select</td><td></td></tr><tr><td>String</td><td>A regular string value.</td><td>String</td><td></td></tr><tr><td>System</td><td>A "System" value. Paired with system/repository specific fields. Can be used with the <code>system field type option</code> in content Motation. <br>A destination connector should check the Motation's top level system attribute to determine if it was generated by a supported system. </td><td>System</td><td></td></tr><tr><td>Tag</td><td>The IDs of the tag objects. </td><td>Tag</td><td></td></tr><tr><td>Text Area</td><td>A text area value. </td><td>Textarea</td><td></td></tr><tr><td>Time</td><td>A time value. Format of value is <code>HH:mm:ss.SSS'Z'</code> . "Zero" value is <code>00:00:00 +0000</code></td><td>Time</td><td></td></tr><tr><td>WYSIWYG</td><td>A WYSIWYG value. </td><td>WYSIWYG</td><td></td></tr></tbody></table>

### Field Mapping

Expanding on the Einstein-Rosen concept, the source connector will take the source repository's content and map the fields of the content to Motation's field types. Then when the destination connector reads the Motation, it knows how to handle each field type of Motation. The following diagram helps illustrate a simple example.

#### No System Fields Support

![Source to Destination Without System Field Support](https://1268830422-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MW_6b8AnMjM58FWM_iK%2Fuploads%2FmeHbb3ywPmjkOralLYu9%2Fconnector-motation-diagram-Page-2.drawio%20\(3\).png?alt=media\&token=cb8888bc-6b17-4958-bc79-e81d24db0d99)

In this diagram We see the source repository has four field types. These field types are all mapped to a field type in Motation. We see that the source "Text" becomes a Motation "String" while "Integer" becomes "Integer." Notice that the source has the "Custom" field type which is stored in Motation as a "System" field type. When this Motation is handled by a destination connector the connector would need specific rules for parsing and handling the value(s). In this example, the destination is not the same system and does not have the rules to handle this "System" field.

However, the destination also has four fields. The destination connector handles Motation field type "String" as a "short text" and "Integer" as "integer." Notice how the "long text" field type is not generated from a Motation field type. The same is true of Column. In this case Motation is built from a repository that the destination repository does not handle the "System" field type from.&#x20;

#### System Fields Support

Now, lets look at an example where the destination repository is the same as the source repository and thus handles all the system specific fields.&#x20;

![Source to Destination With System Field Support](https://1268830422-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MW_6b8AnMjM58FWM_iK%2Fuploads%2FLOJE9uD9B53hj86Kk3XT%2Fconnector-motation-diagram-same%20repos%20example.drawio.png?alt=media\&token=9b26efcf-abb1-4761-b54d-202c9e92a87a)

In this example, we can see that the destination connector makes use of Motation's "System" field type as well as other repository specific attributes in Motation to fully support the source repository's "Column" and "long text" fields.&#x20;

So, Motation directly handles and maps the "short text" and "integer" field at both the source and destination. Motation then handles the "Column" field as a "System" type where the destination connector is able to read repository specific attributes to correctly handle the "Column" field in the destination.&#x20;

Finally, you can see that "long text" on the source is mapped to Motation's "String". However the destination connector is able to sync the source "long text" as a destination "long text." This is due to Motation's "system" attributes. The source connector is able to add additional "system" specific attributes to Motation that the destination connector is able to parse and use. Like the "System" field type, these these system attributes should only be used when the Motation comes from a supported source repository.&#x20;

## Structure <a href="#structure" id="structure"></a>

Below is the structure of the content motation object and what each attribute is for. Every source connector must create a content Motation with the required fields. And every destination connector must support a content Motation with only the required fields.&#x20;

* systems (array | required) the system that the motation came from.
  * name (\*string | required) \*string value with the name of the system
  * date (\*string | required) \*string value with the date the Motation was built from the system
  * version (\*string | optional) \*string value with the version of the system
* dependencies
  * definition (\*string | optional) \*string value with the ID of the definitions motation object
  * domain (\*string | optional) \*string value with the ID of the domains motation object
  * categories (\*string | optional) \*string value with the ID of the categories motation object
  * folders (\*string | optional) \*string value with the ID of the folders motation object
  * languages (\*string | optional) \*string value with the ID of the language motation object
  * relationships (\*string | optional) \*string value with the ID of the relationships motation object
  * tags (\*string | optional) \*string value with the ID of the tags motation object
* contents (\*object | required)
  * id (\*object | required)
    * value (\*string | required) Single ID of the content and it's versions. Always an Impulse ID.
    * label (\*string | optional) Label of the ID.&#x20;
  * properties (\*object | required) The properties for the entire content.&#x20;
    * type (enum | required) The type of content. Either "Content" or "File."&#x20;
    * definitionId (\*string | required) The ID of the associated definition.
    * name (\*string | required) The name of the content.&#x20;
    * status (enum | optional) The status of the content. "None", "Live", "Working", or "Deleted".
    * languageId (\*string | optional) The ID of the associated language.&#x20;
    * description (\*string | optional) The description for the content.&#x20;
    * path (\*string | optional) The path the content lives at.&#x20;
    * site (\*string | optional) The site the content lives at.&#x20;
    * system (\*object | optional) Key/Value repository specific values.&#x20;
    * creationDate (\*string | optional) Creation date of the content.&#x20;
    * modificationDate (\*string | optional) Last modification date of the content.&#x20;
  * versions (\*array | required) An array of the multiple versions of the content.&#x20;
    * id (\*object | required) The id of the version.
      * value (\*string | required) Single ID of the version for the content. Always an Impulse ID.
      * label (\*string | optional) Label of the ID.&#x20;
    * properties (\*object | required) The properties for the specific version.
      * status (enum | optional) The status of the version. "None", "Live", "Working", or "Deleted".
      * name (\*string | optional) The name of the version.
      * order (\*int | optional) The order of the version respective to other versions.
      * creationDate (\*string | optional) The creation date of the version.
      * modificationDate (\*string | optional) The last modification date of the version.
      * modificationUser (\*object | optional) The last modification user of the version.
        * value (\*string | required) Single ID of the modification user for the version. Always an Impulse ID.
        * label (\*string | optional) Label of the ID.&#x20;
      * system (object | optional) Key/Value repository specific values.&#x20;
    * fields (array | required) The list of fields for the version.&#x20;
      * id (\*object | required) The ID of the field.&#x20;
        * value (\*string | required) Single ID of the version for the content. Always an Impulse ID.
        * label (\*string | optional) Label of the ID.&#x20;
      * values (\*array | optional) The list of values for the field.&#x20;
        * value (\*string | required) The value of the field as a string. May be nil when field type is "Binary" or "Relationship.&#x20;
        * order (\*int | optional) The order of all values when multiple values are present. Required when values array is greater than one.&#x20;
        * binary (\*object | optional) The attributes for binary object. Required when fieldType is "Binary."
          * bucket (\*string | required) The bucket the binary data will be stored under. Often times defaulted to the endpoint ID.&#x20;
          * md5 (\*string | required) The md5 of the binary data.
          * filePath (\*string | required) The file path the binary data lives at.&#x20;
          * fileName (\*string | required) The file name of the binary data.&#x20;
        * relations (\*object | optional) The attributes for a relationship field. Required when  fieldType is "Relationship."
          * fieldId (\*object | required) The ID of the field.&#x20;
            * value (\*string | required) Single ID of the version for the content. Always an Impulse ID.
            * label (\*string | optional) Label of the ID.&#x20;
          * parentIds (\*object | required) The ID of the parent content.&#x20;
            * value (\*string | required) Single ID of the parent content. Always an Impulse ID.
            * label (\*string | optional) Label of the ID.&#x20;
          * childIds (\*object | required) The ID of the child content.&#x20;
            * value (\*string | required) Single ID of the parent content. Always an Impulse ID.
            * label (\*string | optional) Label of the ID.&#x20;
            * order (\*int | required) The order of the relationships with respect to other relationships.&#x20;
            * system (object | optional) Key/Value repository specific values.&#x20;
      * fieldType (enum | required) The field type of the field. Must match the field type in definition.&#x20;
      * systemFieldTypeOption (\*string | required) used by the system when fieldType is "System" and for testing.
      * endpointSpecificFieldType (\*string | optional) used by the system for additional rules.&#x20;
      * system (object | optional) Key/Value repository specific values.&#x20;
* audit (\*array | required)
  * date (\*string | required) Date the raw data was picked up.
  * user (\*object | optional) User that picked up the content.&#x20;
    * id (\*object | required) ID of the user.
      * value (\*string | required) Single ID value for the user. Always Impulse ID.&#x20;
      * label (\*string | optional) Label for the ID.&#x20;
    * name (\*string | optional) Name associated with the user.&#x20;
    * email (\*string | optional) Email associated with the user.&#x20;
    * username (\*string | optional) Username associated with the user.&#x20;

## Time Layout

Any date or time attribute in Motation structures or values adhere to the following Golang time layout.

```
2006-01-02 15:04:05 -0700 MST
```

Meaning, when writing a destination connector you can expect that any time field is in uses this layout.&#x20;
