Request Format
{
"request_type":"get_form_metadata",
"form_name_list": [
{"form_name":"Members"}
]
}
You can see from the example that it is possible to request the metadata of an arbitrary number of forms. The form name is given as an object so that it is possible to add parameters to the request for metadata in the future. This may or may not turn out to be useful, but if it is required it will not require restructuring the request levels.
Reply Format
"metadata_list" : [
{
"status" : "success",
"form_data" : {
"form_level_metadata" : {
"form_name" : "Members",
"form_type" : "`Members"
},
"fields_metadata" : {
"0" : {
"field_type" : "FevDescription",
"field_metadata" : {
"labels" : {
"en" : "`Form Name"
},
"field_data_entry_allowed" : false,
"description_upper_case" : false,
"description_maximum_length" : 32
}
},
"5" : {
"field_type" : "FevCode",
"field_metadata" : {
"labels" : {
"en" : "Member Code"
}
}
},
...
This is an incomplete sample of the reply to show how it is structured. The metadata_list is an array of returns for each form name requested.
The status is given for each form.
The form_level_metada gives the form name and the form type. The form type is an internal unique name that is the actual ID of the form. It always starts with a backtick. It doesn’t change, even if the form name is changed.
There may be more form level metadata in the future. Most of the form level metadata is graphical – size, backgrounds etc. and hasn’t been included at the moment.
The fields_metadata is an object using the index of the field as an ID. The type of the field is included and then the metadata is given for the field. It includes the field label (with localized versions) and specialized data that depends on the field type.