Defining Forms

Esta página describe como definir y personalizar formularios y campos in iHRIS definiéndolos en los datos magic . Antes de leer este artículo, por favor lea las generalidades de los formularios y campos para que se familiarice con el modelo de datos de iHRIS.

Formularios

Los formularios son la manera básica de agrupar los datos. Un formulario $form, como 'person', se guarda bajo:

/modules/forms/forms/$form

y contiene los siguientes secundarios:

• class: Requerido. La clase que implementa la lógica, como la validación par ael formulario. Ejemplo es 'iHRIS_Person'.
• displayName: Opcional. Un nombre de usuario final para este formulario. Por ejemplo. 'person' podría tener el display name 'Person'
• storage: Opcional. Por defecto esta establecido en 'entry.' Es el mecanismo de almacenamiento que debe usar el formularios
• meta: Opcional. Un nodo con muchos secundarios donde se guarda la información acerca de como se muestra este formulario, Los datos aqui se utilizan por la clase del formulario que tiene la función de implementación
  • description: Una descripción de este formularios. Se muestra, por ejemplo, al crear una relación del formulario
  • child_forms: Una lista de todos los formularios que son secundarios o hijos de este formulario.
  • child_form_data: Opcional. Son metadatos asociados con los formularios secundarios. Posiblemete hay un nodo por cada uno de los formularios secundarios.

Los nodos en los formularios secundarios permiten identificar diferentes agrupaciones para ls formularios secundarios. Por ejemplo el formulario 'training_course' tiene un formulario secundario 'scheduled_training_course.' Sería conveniente agrupar 'scheduled_training_courses' en open y closed. Entonces podemos seleccionar los cursos programados que estan abiertos o cerrados al especificar los limites como se muestra abajo. También podemos escoger especificar el orden en que se muestran los cursos programados. Por ejemplo:

'default'  => Array [
 'scheduled_training_course' => Array [
  'order' => 'start_date,end_date' 
 ] 
]
'open' => Array [
 'scheduled_training_course' => Array [
  'limits' => Array [
    'operator' => 'FIELD_LIMIT'
    'field' => 'start_date'
    'style' => 'greaterthan_now'
  ]
  'order' => 'start_date,end_date'
 ] 
]
'closed' => Array [
  'scheduled_training_course' => Array [
   'limits' => Array [
     'operator' => 'FIELD_LIMIT'
     'field' => 'start_date'
     'style' => 'lessthan_now'
   ]
   'order' => 'start_date,end_date'
 ] 
]

Los límites se especifican de acuerdo a esta estructura. El 'order' es una lista de los campos en los cuales se dividirá la clasificación. En el ejemplo anterior los clasificamos primero por 'start_date' y luefo por 'end_date.' Si quisieramos clasificarlos por un campo en orden descendiente utilizaríamos una - como prefijo.

Componentized Forms

If you are setting up an aggregating instance of iHRIS Manage (or Qualify) some of your forms will be componentized. This means that the data for each of these forms is being managed by distinct localities (e.g. regions or districts or even departments) and you wish to aggregate this de-centralized data. Whether or not a form is localized is determined the form storage mechanism being used. If a form is componentized, then any id's that reference that form are appended with an '@' and the name of the component.

Form Classes

A form class $formClass is defined under:

/modules/forms/formClasses/$formClass

It has sub-nodes:

• fields: Optional. Contains information about the fields provided by this class
• extends: Required. Which class this form class extends. This needs to be either I2CE_Form or a subclass of it.

Dynamic Creation

If there is no file $formClass.php then the class is created dynamically as:

class $formClass extends $extendClass {}

where $extendClass is the value under the 'extends' node.

Lists

The form class I2CE_List is a special form which allows you to deal easily with lists of data. Any mapped field should take values in a form whose implementing class is a subclass of I2CE_List.

I2CE_List has a subclass I2CE_SimpleList whose only field is 'name'. Examples of simple lists are:

• gender
• marital_status
• language

Magic Data for Lists

A list is defined by its magic data in a form class, $listClass. Under the magic data node:

/modules/forms/formClasses/$listClass/meta

as follows:

• list: An optional parent node. Each child node is a named "display" for this list which can be referenced in .html templale files.
  • default: Optional parent node. When displaying a field, if no display is specified, the data under the node "default" is used to determine the display.
    • display_string: The printf style display string used to display this form in a drop down or tree select. Defaults to "%s".

      The printf substitutions is according to this. Please note that if there is more than one field to be substituted, you should use references/arguments so that translators can handle this appropriately. So instead of "%s %s" you would use "%1$s %2$s"

    • display_args: The fields which are passed to display_string to be printed. Defaults to having one child with key 0 and value "name" (although this field may not exist!)
      • 0: Scalar node. The name of a field in this form.
      • 1: Scalar node. The name of a field in this form.
      • 2: Scalar node. The name of a field in this form.
      • ...: There should be the same number of children as there are referenced substitutions in display_string
    • sort_fields: Optional parent node. The ordering that should be applied when displaying this list. Children are scalar nodes with keys integers and values the name of the field. Defaults to having one child with key 0 and value "name" (although this field may not exist!)
  • $display1: Optional parent node. Structure is the same as the "default" above.
  • $display2: Optional parent node. Structure is the same as the "default" above.

Fields

Information on Form Fields