Defining Forms: Difference between revisions

From IHRIS Wiki
Line 58: Line 58:
donde $extendClass es el valor bajo el nodo 'extends'.
donde $extendClass es el valor bajo el nodo 'extends'.


===Lists===
===Listas===
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.
La clase del formulario I2CE_List es un formulario especial que permite manejar listas de datos. Cualquier campo mapeado debe tomar valores en un formulario cuya clase que implementa es una sub-clase de I2CE_List.


I2CE_List has a subclass I2CE_SimpleList whose only field is 'name'.  Examples of simple lists are:
I2CE_List tiene una sub-clase I2CE_SimpleList cuyo único campo es 'name'.  Algunos ejemplos de listas simples son:
*gender
*género
*marital_status
*estado_civil
*language
*idioma


===Magic Data for Lists===
===Magic Data for Lists===

Revision as of 09:03, 29 September 2013

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 luego por 'end_date.' Si quisieramos clasificarlos por un campo en orden descendiente utilizaríamos una - como prefijo.

Formularios por Componentes

Si esta estableciendo una instancia que podrá agregar elementos en iHRIS Manage (o Qualify) algunos de sus formularios serán por components. Esto significa que los datos serán manejados por diferentes localidades (es decir, regions o distritos o incluso departamentos) y usted quiere agregar estos datos decentralizados. Si un formulario es localizado o no, es determinado por el mecanismo de almacenamiento del formulario que se este utilizando. si un formulario es por componentes, entonces todas las id que hacen referencia a ese formulario tendrán adjunta una '@' y el nombre del componente.

Clases de Formularios

Una clase de un formulario $formClass se define bajo:

/modules/forms/formClasses/$formClass

Tiene sub-nodos:

  • fields: Opcional. Contiene informacion acerca de los campos proporcionados por esta clase
  • extends: Requerido. La clase que extiende la clase de este formulario. Esto debe ser I2CE_Form o una sub-clase del mismo.

Creación Dinámica

Si no hay archivo $formClass.php entonces la clase se crea dinámicamente como:

class $formClass extends $extendClass {}

donde $extendClass es el valor bajo el nodo 'extends'.

Listas

La clase del formulario I2CE_List es un formulario especial que permite manejar listas de datos. Cualquier campo mapeado debe tomar valores en un formulario cuya clase que implementa es una sub-clase de I2CE_List.

I2CE_List tiene una sub-clase I2CE_SimpleList cuyo único campo es 'name'. Algunos ejemplos de listas simples son:

  • género
  • estado_civil
  • idioma

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