Specifiers
There are two types of specifiers: Validation Specifiers and Representation Specifiers.
Both specifiers are defined inside the param field. The Representation Specifiers define how the requested data will be rendered in the UI.
Validation Specifiers define valid values that can be assigned to the fields of the objects (Edits, Edges, Tags) that will be created using the Invitation. Most Validation Specifiers outside content do not require a type
field since its type can be inferred from the field name. For instance, the readers field will always be of type group[]
. However, other Validation Specifiers need to be defined for the readers field, such as regex.
Only the mandatory fields head and tail in an Edge must specify the field type even though they are not inside a content field.
Validation Specifiers inside the content
field will always require a type
. This is because content
can have any field name and its valid values need to be specified so that the UI can render them and the backend validate them.
In most cases, you can only have one Validation Specifier. The only exceptions are value range specifiers, such as minimum
, maximum
, minLength
and maxLength
.
There is no restriction on the amount of Representation Specifiers.
Value Pattern or Validation Specifier
The param
should have one of the following specifiers needed to validate the expected value.
Whenever param
is present, the user is expected to input a value for that field. Otherwise, the value is considered to be a constant and the user cannot change it.
const
: restricts the value of the field to whatever it's written in const. Whenconst
is present, the user does not need to pass the value, since it will be assigned by the Invitation. In the example below, the title value has to be exactly "This is a title".
It is preferred to use the following shorthand whenever possible, which is the same as the example above:
Fields that are specified as constants in the Invitation do NOT need to be passed when creating an object (Note Edit, Invitation Edit, Group Edit, Tag, or Edge).
enum
: valid values must be listed in the enum array. The values inenum
must be of the same type and should match the type specified in the field type. When the type ofenum
is string its values can be regexes too. In the example below "This is a title" and "This issss b regex" are valid values for title.
regex
: valid values need to match the specified regex. The type of the field should be string. In the example below, "This asdf title" is a valid value.
range
: valid values are within the range [a, b] which means a <= value <= b. The type of the field must be float or integer. In the example below, the values 0, 3, and 10 are valid.
withInvitation
: valid values are IDs of entities that have as invitation the value specified inwithInvitation
.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "or2022" would be valid.
withVenueid
: valid values are IDs of entities that have asvenueid
the value specified inwithVenueid
.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "or2023" would be valid.
withForum
: valid values are IDs of entities that have as forum the value specified inwithForum
.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "com2024" would be valid.
inGroup
: valid values are group IDs that are members of the group ID specified ininGroup
.
Suppose we have the following group (this is a simplified version of the group):
Given the example below, the value "~Some_Reviewer1" would be valid.
Value Range or Domain Specifiers
minLength
: valid values are strings that have at least the length specified inminLength
. In the example below, the values "title" and "long title" are valid.
maxLength
: valid values are strings that have at most the length specified inmaxLength
. In the example below, the values "title" and "abc" are valid.
maxSize
: specifies the maximum size that a file can have in megabytes. It must be used with type file. In the example belowextensions
: specifies the valid types with the extension of the file. The extensions cannot have dots, which means that files that have the extension tar.gz are not supported.
minimum
: valid values are numbers (floats or integers) that have at least the value specified inminimum
. In the example below, 1 and 6000 are valid values.
maximum
: valid values are numbers (floats or integers) that have at most the value specified inmaximum
. In the example below, 20.5 and 16.7 are valid values.
Field attributes
type
: define the type value that field is going to have.
The field type
is mandatory in all the fields whose type cannot be determined by the name of the field. Note how in the example below the field invitation/edit/signatures defines param/regex without a type keyword. This is because we know the type of the field signatures
. We know is of type groups[]
, so there is no need to define it. On the other hand, the field invitation/edit/note/content/title/value
has to define the type since the fields inside content can be anything.
Allowed types:
string
integer
boolean
date
file
profile
group
note
The field types profile, group, and note ask for an ID, not the entire object.
Square brackets can be appended to each type to expect an array of values, for example:
Not all types can become arrays. The exceptions are date
and file
.
type
can be an optional property in some cases where it is known which type is expected, for example: readers
, writers
and signatures
of a note.
optional
: boolean value that indicates if the value is optional or mandatory.deletable
: boolean value that indicates if the value can be deleted.
The fields optional and deletable can be used at the same time or omitted. Their behavior is defined below:
True
True
Field is optional and can be deleted
True
False
Field can be added but not deleted
False
True
Undefined
False
False
Field is mandatory and cannot be deleted
True
undefined
Field can be added but not deleted
undefined
True
Field is optional and can be deleted
undefined
undefined
Field is mandatory and cannot be deleted
Representation specifiers
Representation specifiers are not used for validation, they are only used to correctly display the data in the UI. They are not mandatory and in case they are not present the UI will have default values for each field.
order
: define the order in which the field is going to be rendered in the form.description
: short text to explain the expected value.input
: type of widget to use when requesting data.text
select
checkbox
textarea
radio
default
: value that is going to be shown when the widget is initialized.markdown
: boolean value that enables the use of markdown.scroll
: boolean value that specifies whether a textarea input will be scrollable.
Last updated