Field settings.php

From ARK
Revision as of 10:01, 20 November 2011 by Jessogden (talk | contribs) (Other Obligatory Settings)

Jump to: navigation, search

This is the documentation for the field settings file. It contains a technical description of the elements that must be and may optionally be present in fields.

Common/Obligatory Attributes


The two top settings are essential for the good working of the field:

  • dataclass = This tells the system what Data Class the field is.
  • classtype = This tells the system what Classtype the field is.

There is not currently an ARK function to create new classtypes. In order to add a new classtype, please access the database using PHPMyAdmin and add the classtype directly in the cor_lut_classtype table (eg. cor_lut_actiontype, cor_lut_datetype, etc...).


As of v0.8 fields now have the option of being made 'sortable' in the data view (search). In order to allow for ascending and descending sorting on fields a 'field_id' must be added to the fields of interest, rendering them sortable in the search results table view.

  • field_id = This is set to the name of the field, i.e. for field 'conf_field_textdesc', the 'field_id' => 'conf_field_textdesc'

Alias Settings

The alias for the field requires the following 4 attributes:

  • alias_tbl = the table for the getAlias call
  • alias_col = the col for the getAlias call
  • alias_src_key = the alias_src_key for the getAlias call
  • alias_type = the alias_type for the getAlias call

It is important to add all alias values to cor_tbl_alias when configuring fields. This can be completed using the Alias Administration tools.

Other Obligatory Settings

  • editable = set TRUE to process this field in forms set FALSE for display only
  • hidden = 1/TRUE | 0/FALSE/blank | string (see below)
  • add_validation = validation rules for this field when on an add routine
  • edt_validation = validation rules for this field when on an edt routine

editable This is to with how the system processes As of v1.1 this variable only affects the way update_db processes fields - not the user interface. 1/TRUE - handles field as normal 0/FALSE - update_db will ignore this field (e.g. options field)


This variable is processed by frmElem() and is a setting which allows admins to a hide a given field from user input. If hidden a default needs to be supplied so that the input is supplied with a variable. The only dataclasses that has implemented this option as of v1.1 are xmi and itemkey. Variable will be ignored on all other dataclasses, but still obligatory as this will implemented in the future.

  • 1/TRUE - field is hidden, input type = hidden (needs default supplied, as mentioned above)
  • 0/FALSE - user input form displayed as normal
  • string - nname which adds the markup for label displayed in form, functions the same as TRUE


An example of a standard text field:

$conf_field_desc =
        'dataclass' => 'txt',
        'classtype' => 'desc',
        'alias_tbl' => 'cor_lut_txttype',
        'alias_col' => 'txttype',
        'alias_src_key' => 'desc',
        'alias_type' => '1',
        'editable' => TRUE,
        'hidden' => FALSE,
        'add_validation' => $txt_add_validation,
        'edt_validation' => $txt_edt_validation

An example of a standard attribute field:

$conf_field_samplecondition =
        'dataclass' => 'attr',
        'classtype' => 'samplecondition',
        'alias_tbl' => 'cor_lut_attributetype',
        'alias_col' => 'attributetype',
        'alias_src_key' => 'sampleconditions',
        'alias_type' => '1',
        //'alias_classtype' => 'Condition',
        'editable' => TRUE,
        'hidden' => FALSE,
        'add_validation' => $attr_add_validation,
        'edt_validation' => $attr_edt_validation

An example of a standard number field:

$conf_field_total =
        'dataclass' => 'number',
        'classtype' => 'total',
        'alias_tbl' => 'cor_lut_numbertype',
        'alias_col' => 'numbertype',
        'alias_src_key' => 'total',
        'alias_type' => '1',
        'editable' => TRUE,
        'hidden' => FALSE,
        'add_validation' => $number_add_validation,
        'edt_validation' => $number_edt_validation

An example of a standard date field:

$conf_field_issuedon =
        'dataclass' => 'date',
        'datestyle' => 'dd,mm,yr',
        'classtype' => 'issuedon',
        'alias_tbl' => 'cor_lut_datetype',
        'alias_col' => 'datetype',
        'alias_src_key' => 'issuedon',
        'alias_type' => '1',
        'editable' => TRUE,
        'hidden' => FALSE,
        'add_validation' => $date_add_validation,
        'edt_validation' => $date_edt_validation

An example of a standard span field:

$conf_field_sameas =
       'dataclass' => 'span',
       'classtype' => 'sameas',
       'alias_tbl' => 'cor_lut_spantype',
       'alias_col' => 'spantype',
       'alias_src_key' => 'sameas',
       'alias_type' => '1',
       'editable' => TRUE,
       'hidden' => FALSE,
       'add_validation' => $span_add_validation,
       'edt_validation' => $span_edt_validation

An example of a standard xmi field:

$conf_field_romxmi = 
        'dataclass' => 'xmi',
        'classtype' => 'xmi_list',
        'alias_tbl' => 'cor_tbl_module',
        'alias_col' => 'itemkey',
        'alias_src_key' => 'rom_cd',
        'alias_type' => '1',
        'module' => 'mus',
        'xmi_mod' => 'rom',  
        'op_xmi_itemkey' => 'rom_cd',
        'editable' => TRUE,
        'hidden' => FALSE,
        'add_validation' => $xmi_add_validation,
        'edt_validation' => $xmi_edt_validation

And finally, an example of a standard file field:

$conf_field_file =
      'dataclass' => 'file',
      'classtype' => 'file',
      'alias_tbl' => 'cor_tbl_col',
      'alias_col' => 'id',
      'alias_src_key' => '6',
      'alias_type' => '1',
      'editable' => TRUE,
      'hidden' => FALSE,
      'add_validation' => $file_add_validation,
      'edt_validation' => $file_edt_validation

Class specific settings

Each class has some specific settings some of which may be optional or required.

Class: action

An example of an action class field.

$conf_field_issuedto = 
        'dataclass' => 'action',
        'classtype' => 'issuedto',
        'alias_tbl' => 'cor_lut_actiontype',
        'alias_col' => 'actiontype',
        'alias_src_key' => 'issuedto',
        'actors_mod' => 'abk',
        'actors_type' => 'people',
        'actors_element' => 'name',
        'actors_style' => 'single',
        'actors_elementclass' => 'txt',
        'actors_grp' => FALSE,
        'alias_type' => '1',
        'editable' => TRUE,
        'hidden' => FALSE,
        'add_validation' => $action_add_validation,
        'edt_validation' => $action_edt_validation
  • actors_mod = The module holding the actors (normally abk)
  • actors_type = The mod type as listed in mod_lut_modtype
  • actors_element = The text type to display within the dropdown
  • actors_style = whether actor information is displayed in a list style ('list') or as a single actor/date pairing ('single')
  • actors_elementclass = Class of data to be displayed for a given actor (ie. txt, number, etc)
  • actors_grp = Group functionality will allow the selection of a group of actors (in development)

Event Fields

Event fields are effectively wrappers for action/date fields. All fields must be set up above. One can also use actions and dates without having the event wrapper, but this allows one to group multiple events into a single subform.

See below for an example of a configured event field:

$conf_event_compiled = 
        'type' => 'compiled',
        'date' => $conf_field_compiledon,
        'action' => $conf_field_compiledby