Form Fields

Este artículo define los tipos de datos principals o campos de formlarios utilizados por iHRIS. Estos campos se definen en Datos Magic y a continuación se describen los detalles de como deben definirse.

Magic Data for Defining Fields

Each form class $formClass contains a list of fields. A field $field in $formClass is defined at:

/modules/forms/formClasses/$formClass/fields/$field

which has the following sub-nodes

• formfield: Required. Needs should be on of the field type such as INT
• in_db: Optional. It should be either 0 or 1. If not set, defaults to 1. If 1, then this field should be saved into the database
• required: Optional. It should be either 0 or 1. If not set, defaults to 0. If 1, then this field needs to be set before it can be considered valid
• unique: Optional. It should be either 0 or 1. If not set, defaults to 0. If 1, then the value of this field needs to be unique among all instances of the form
• headers: Optional. It is itself a parent node, each child node is a string value. You can choose a different header by specifying the header attribute in a template file.
  • default: Optional scalar node. The default title/header displayed for the field. This header is used if no header attribute is specified in the tempalte.
  • $display1: Optional scalar node. Same as 'default'
  • $display2: Optional scalar node. Same as 'default'
  • ...

Field Types

Each field has a type. The types define how they are displayed to the end user in both an edit and view only context. It also contains information about the type of column the data should be saved in a database. The available types are:

• BOOL is implemented by the class I2CE_FormField_BOOL is a choice between true and false
• CURRENCY is implemented by the class iHRIS_FormField_CURRENCY and is a currency type and an amount
• DATE_HMS is implemented by the class I2CE_FormField_DATE_HMS is a time only
• DATE_MD is implemented by the class I2CE_FormField_DATE_MD is a month and day
• DATE_TIME is implemented by the class I2CE_FormField_DATE_TIME is a year, month, day and time
• DATE_YMD is implemented by the class I2CE_FormField_DATE_YMD and is a year, month and day
• DATE_Y is implemented by the class I2CE_FormField_DATE_Y and is a year
• INT_GENERATE is implemented by the class I2CE_FormField_INT_GENERATE and is integer sequence that will populate the next value in the sequence
• INT is implemented by the class I2CE_FormField_INT is an integer
• INT_LIST is implemented by the class I2CE_FormField_INT_LIST is an array of integers
• INT_RANGE is implemented by the class I2CE_FormField_INT_RANGE is a ranged drop down of integers and was introduced in version 4.1. The range is specified by setting start (defaults to 0), end (defaults to 10) and step (defaults to 1) in the meta section of the field's options.
• MAP is implemented by the class I2CE_FormField_MAP and is the name and id of a list form
• MAP_MULT is implemented by the class I2CE_FormField_MAP_MULT and is an array of names and ids for list forms
• REFERENCE is a field which is a reference to another form and whose display value is based on the fields in that referenced form. You can see the defintion here
• STRING_LINE is implemented by the class I2CE_FormField_STRING_LINE and is a string
• STRING_MLINE is implemented by the class I2CE_FormField_STRING_MLINE and is multi-line string
• STRING_PASS is implemented by the class I2CE_FormField_STRING_PASS is a password value
• STRING_TEXT is implemented by the class I2CE_FormField_STRING_TEXT is a large multi-line string
• YESNO is implemented by the class I2CE_FormField_YESNO and is a choice between Yes and No

Map Fields

A MAP or MAP_MULT takes values in a list, which is any form whose implementing class subclasses I2CE_List. There are some special options for how these lists are displayed.

Datos Magic Meta para Campos Fields

Un campo de tipo MAP o MAP_MULT puede especificar el siguiente sub-nodo 'por defecto' . Bajo el nodo de datos magic:

/modules/forms/formClasses/$formClass/fields/$field/meta

Podemos especificar más información que afecta como se utiliza un campo de la siguiente manera:

• form: un nodo primario opcional. Los nodos secundarios on todos escalares que especifican los formularios en los que este campo puede tomar valores. Si no se establece, el nombre del formulario se assume como el nombre del campo, $field.
• display: un nodo primario opcional. Cada nodo secundario es "named" mostrado para ese campo que puede referenciarse en archivos de plantillas .html .
  • default: un nodo primario opcional. Al mostrar un campo, si no se especifíca el display, se utiliza el nodo "default" para determinar el display.
    • fields: Nodo escalar opcional. Este nodo describe la jerarquía de como se deben mostrar los datos, por ejemplo, en una vista de árbol de llos mosmos, al seleccionar el valor de est campo. Tiene la estructura general "mapform1+mapfield1:mapform2+mapfield2:...:mapformN". Si el +mapFieldX no está presente, entonces utiizamos mapFormX+1 para el valor de mapFieldX. Si la entrada de los 'fields' no está establecida, entonces el nombre del campo es el formulario mapeado.
      Cuando seleccionamos un valor para el campo, empezamos por mostrar todos los valores para mapFormN. Bajo cada uno de estos valores, mostramos todos los valores de mapFormN-1 cuyo campo mapFieldN-1 es mapFormN es y continuamos hasta llegar a mapForm1.
      Si mapFormXX+mapFieldXX esta rodeado por por corchetes cuadrados, [ ], entonces no mostramos los datos de ese formulario mapeado.
    • orders:un nodo primario opcional. Los nodos secundarios tienen nombres que son formularios que podemos seleccionar por el campo:
      • $form1: un nodo primario opcional. Los secundarios son nodos escalares con claves enteros y valores del nombre del campo. Si este nodo está establecido, entonces sobreescribirá cualquier valor que se establezca bajo el nodo de datos magic: /modules/forms/formClasses/$form1/meta/list/default/sort_fields.

        Note: even if this is $display1, then it will still look at default/sort_fields rather than $display1/sort_fields)

      • $form2: Nodo primario opcional. Misma estructura que $form1.
      • ...:
  • $display1: Nodo primario opcional. La estructura es la misma que el display "por defecto" .
  • $display2: Nodo primario opcional. La estructura es la misma que el display "por defecto" .
  • ...
• limits: Nodo primario opcional. Los nodos secundarios describen los límites que deben aplicarse al llenar la lista o el árbol de entradas válidas
  • default: Nodo primario opcional. límites que se aplican al display por defecto. Los secundarios se nombran para cada una de los formularios que podemos seleccionar referenciados en la lista de 'form' anterior.
    • $form1: Nodo primario opcional. Límites que aplican al ller los datos de $form1 en la base de datos. La estructura de este nodo es la misma estructura de Limiting Forms
    • $form2: Nodo primario opcional. Límites que aplican al leer los datos de $form2 en la base de datos. La estructura de este node es la misma estructura de Limiting Forms
    • ...
  • $display1: Nodo primario opcional. Límites que aplican al display $display1. Misma estructura que 'por defecto'
  • ...

Vea también: Defining List Forms

Ejemplo de Datos Magic Meta

Por ejemplo, iHRIS_Person tiene un campo mapeado, 'residence'. Su nodo meta contiene los siguientes sub-nodos: <source lang='php'> 'form' => Array [

         0 => county
         1 => district
         ],

'display' => Array [

     'default' => Array [
       'fields' => county:district:[region]:country 
       ] 
   ],

'limits' => Array [

   'default'=> Array [
       'country'=> Array[
           'operator'=>'FIELD_LIMIT',
           'field'=>'location',
           'style'=>'yes'
        ]
    ] 

] </source> También puede ver .xml que se utiliza para definir esto en los datos magic para el modulo de Person en iHRIS Common.

En este caso, el nodo 'forms' nos dice que cualquier miembro de la lista de distritos o condados se puede escoger como la residencia de una persona.

En el ejemplo anterior, al seleccionar una residencia para una persona, primero debe escoger el país, luego la región, luego el distrito. Puede especificar aún más el condado. Cuando se muestre una residencia se verá como:

District, Country

o

County, Country District

dependiendo se si seleccionó el distrito o condado.

Automatically Generated Integers (INT_GENERATE)

Automatically generated integers (or INT_GENERATE) are used when a form needs an incremented number to use for an ID but the data entrant may not know what the next available value is. The user can check a checkbox to increment to the next value or if necessary can type in the number if it is known. As of version 4.0.2 INT_GENERATE is only supported when the form uses the entry form storage mechanism. It uses the field_sequence table to keep track of the current maximum value for each form field.

In the field_sequence table there will be an entry with the form field id and the highest value that has been used. The system checks two possibilities for determining the next available number. It looks at the field_sequence table if a row exists there for the form field and in the last_entry table for the highest assigned value. Whichever is higher is then incremented by one and saved to the field_sequence table so it can be accessed the next time a record is added.

If you want to start at 1000 you can just add the form field id and 1000 to field_sequence. You only need to add something to the field_sequence table if you want it to start higher than the currently saved values. For example, if you imported data that ranges from 100-400 but you want the generated numbers to start at 1000 then you’ll need to add a row to the field_sequence table. But if you just want the next number to be 401 then you don’t need to do anything.