Creating new Content Types¶
A new Content Type can be created either by sending a properly formatted POST request to the /api/v1/internal/contenttype
endpoint or through the Content Modeler tool provided with the platform.
Creating new Content Types via API¶
The API endpoint /api/v1/internal/contenttype
can be used to interact with Content Type Definitions inside the Content Repository. The endpoint documentation is provided in the API docs and describes the following actions:
Creating a new Content Type is simply a POST
call with a payload similar to:
Content Type POST payload
{
"name": "blogposts",
"label": "Blog Posts",
"schemaDefinition": {
"type": "object",
"allOf": [
{
"$ref": "#/components/schemas/AbstractContentTypeSchemaDefinition"
},
{
"type": "object",
"properties": {
"title": {
"type": "string"
},
"postContent": {
"type": "string"
}
}
}
],
"required": [
"title",
"postContent"
],
"additionalProperties": false
},
"metaDefinition": {
"propertiesConfig": {
"title": {
"label": "Title",
"inputType": "text",
"unique": true
},
"postContent": {
"label": "Post content",
"inputType": "richtext",
"unique": false
}
},
"order": [
"title",
"postContent"
]
}
}
name
is the name of the Content Type and name of the endpoints that will be generated to handle requests with Content Objects of that type.
label
is only for displaying the name correctly on the CMS panel.
The schemaDefinition
part of the JSON payload is based on the bare JSON Schema and is fully compatible. It holds information about properties of the CT (in the properties
key), its types and which properties are required (required
key). It always should have "type": "object"
, as it is an object, and "additionalProperties": false
to ensure that API users will not post garbage to the objects of this CTD. To ensure that all objects have id property CTD also should have information about the connection with AbstractContentTypeSchemaDefinition
using:
"allOf": [
{
"$ref": "#/components/schemas/AbstractContentTypeSchemaDefinition"
}
],
In the case of this example, it will add two properties, title
and postContent
which are both strings and required.
metaDefinition
is used to tell CMS panel how to render a form for the Content Object, it holds information about the order of the properties (order
key, which should contain all properties of the object), and about type and validation of the field. It also includes information on relations of the object with other Content Types.
In this case, Blog Post will have title
property which will be unique and will render as text input in CMS panel and postContent
which can be duplicated and will be presented as CKEditor input in CMS panel. First input in the form in CMS panel will be title
input, and second will be postContent
.
Full curl request:
curl -X POST "https://api.flotiq.com/api/v1/internal/contenttype" -H 'accept: */*' -H 'X-AUTH-TOKEN: YOUR_API_KEY' -H 'Content-Type: application/json' --data-binary '{"name":"blogposts","label":"Blog Posts","schemaDefinition":{"type":"object","allOf":[{"$ref":"#/components/schemas/AbstractContentTypeSchemaDefinition"},{"type":"object","properties":{"title":{"type":"string"},"postContent":{"type":"string"}}}],"required":["title","postContent"],"additionalProperties":false},"metaDefinition":{"propertiesConfig":{"title":{"label":"Title",inputType":"text","unique":true},"postContent":{"label":"Post content","inputType":"richtext","unique":false}},"order":["title","postContent"]}}'
After such call is made and Content Type is created - the User API is immediately extended to support interaction with this new Content Type:
All Content Types have automatically added properties from AbstractContentTypeSchemaDefinition
; they are:
- id - string identifier of Content Object, required in all requests, unique within the Content Type,
- internal - object necessary to proper work of CMS backend (information about dates of creation and update, the whole object is described in JSON below).
Schema of Abstract Content Type
"AbstractContentTypeSchemaDefinition": {
"type": "object",
"properties": {
"id": {
"type": "string"
},
"internal": {
"type": "object",
"additionalProperties": false,
"required": [
"createdAt", "updatedAt", "deletedAt", "contentType"
],
"properties": {
"contentType": {
"type": "string"
},
"createdAt": {
"type": "string"
},
"updatedAt": {
"type": "string"
},
"deletedAt": {
"type": "string"
}
}
}
},
"required": [
"id"
]
},
Property types¶
Property types (as of schemaDefinition
properties), recognized by CMS panel:
Property types
type | Description | Additional keys in property | Description |
---|---|---|---|
string | Any string data that includes date and files | none allowed | |
number | Any number, integer, float and double | none allowed | |
boolean | Represents two values true and false . Note that truthy and falsy values such as "true", "", 0 or null are not considered boolean values. |
none allowed | |
array | Used for lists or relations. | items | For relations: it has to be an object containing {"$ref": "#/components/schemas/DataSource"} , as the items of the array are objects described in DataSource schema.For list items: it should be a valid json schema following the same restrictions as wrapping schema |
minItems | 0 for a not required property, and 1 for required property |
||
object | Used for geo point type | properties | must be {"lat": {"type": "number"},"lon": {"type": "number"}} |
additionalProperties | must be false |
||
type | must be object |
||
required | if the field is required it must be ["lat","lon"] |
Meta definition properties types¶
Input types in metaDefinition
of properties:
Meta definition
inputType | Possible for schema type | Description | Additional keys in property | Description | Additional keys | Description |
---|---|---|---|---|---|---|
text | string | Renders text input in form | unique | * | none allowed | |
textarea | string | Renders textarea in form | unique | * | none allowed | |
richtext | string | Renders CKEditor in form | unique | * | none allowed | |
string | Renders email input in form | unique | * | none allowed | ||
number | number | Renders number input in form, min is 0, max is MAX INT | unique | * | none allowed | |
radio | string | Renders radio input, options are taken from options property |
unique | *, Can only be false |
none allowed | |
options | Array of string options possible for the radio input | none allowed | ||||
checkbox | boolean | Renders single checkbox input returning true /false value |
unique | *, Can only be false |
none allowed | |
select | string | Renders single item select input, options are taken from options property |
unique | * | none allowed | |
options | Array of string options possible for the select input | none allowed | ||||
object | array | Renders one or multiple forms for nested meta definition element |
items | Meta definition for single list item |
same as in wrapping meta definition (order and propertiesConfig ) |
|
datasource | array | Renders picker for choosing the objects of specified or any other Content Type, depending on validation property |
unique | * | none allowed | |
validation | Object contains restrictions for datasource | relationContenttype | Name of the Content Type to which relation should be restricted | |||
relationMultiple | Boolean value informing if the array should have only one ora can have more elements | |||||
geo | object | Renders two fields, one for the latitude, second for the longitude, saves it as an object | unique | * | none allowed |
*Information if the value of the property should be unique in all object of the specified type.
Creating Content Types through the Content modeller¶
It is described in the public part of the documentation.