Forms and Form Classes

From IHRIS Wiki

Los registros se guardan en el Intrahealth Informatics Core Engine (I2CE) en formularios que consisten de una colección de campos. Se puede pensar en un formulario como una tabla en una base de datos y un campo como una columna de esa tabla.

La lógica de un formulario se maneja por medio de una Form Class que extiende I2CE_Form. La lógica de un campo se maneja por medio de una clase que extiende I2CE_FormField.


Referencias en Plantillas

El sistema de templating permite la fácil referencia de los datos duardatos en un formulario en una plantilla html. Por ejemplo para hacer referencia al primer nombre de una persona puede utilizar:

<p  id='my_person'>You are looking at <span type='form' name='person:firstname'/> <span type='form' name='person:surname'/>!</p>

Se convertiría en

<p id='my_person'>You are looking at Joe Smith!</p>

si hubiera un formulario de 'person' en el nodo o arriba de este con id 'my_person'. El html se modifica por medio del sistema de plantillas. En la versión 3.1, esto se realiza con el método 'processForms()' de la clase del modulo del forms , I2CE_Module_Forms, por medio de hooking en los 'process_templatedata_FORM' definidos en I2CE_Module_TemplateData.

Es responsabilidad de la página asegurarse de que el formulario adecuado se asigne al nodo adecuado en la plantilla.

Formularios y sus Clases

Un formulario $form esta vinculado a una clase de formulario al especificar los datos en /modules/forms/forms/$form/class para ser el nombre de la clase del formulario. For ejemplo:

I2CE::getConfig()->modules->forms->person->class = 'I2CE_ManagePerson';

Las clases pueden o no existir como archivos. Si hay datos lógicos que un formuulario debe desarrollar, por ejemplo existirá en su métodos validate() y save() . De lo contrario, existen virtualmente. A partir de la versión 3.2 tales como una clase virtual se generan automaticamente utilizando el método __autoload() .

Fields and Their Clases

All fields of a form have a name and a type. The name of the fields is how the field is referenced by the form as a public variable by using the __get() and __set() methods. For example:

if ($person instanceof I2CE_Person)  {
 echo "$person->firstname . "\n";
}

The types effect how the data is stored in the database and how the data is displayed and entered in the system. The following are a list of common types:

  • BOOL A boolean True/False value
  • CURRENCY A currency value
  • DATE_HMS A hour, minute, second time
  • DATE_MD A month and date
  • DATE_TIME A time
  • DATE_Y A year
  • DATE_YMD A year, month and date
  • INT An integer value
  • INT_LIST A list of integers
  • INT_GENEREATE An integer which automatically increments
  • STRING_LINE A line of text
  • STRING_MLINE Several lines of text
  • STRING_PASS A password
  • STRING_TEXT A lot of text
  • YESNO A Yes/No value

A $type is handled by the class I2CE_FormField_$type

Forms and Their Fields

The structure of forms, their classes and fields and where they are defined in can be easily browsed at:

How the Data is Stored

Although you may loosely think of a form as being a table in the database, it is not quite so.

Version 3.1

In version 3.1 all data stored in forms is stored in the 'entry' and 'last_entry' tables. These tables keep a history of the changes made to the data based on the user that changed the data, the type of the change, and the time of the change. The 'entry' table has all of the history, while the 'last_entry' table only contains the most recent changes to a field.


Version 3.2

Starting in this version we are enabling multiple storage mechanisms for a form. The default storage mechanism will still be through the 'entry' and 'last_entry' table.

In addition we will enable storage to specified database tables to allow the administrator to easily incorporate outside data sources into the Custom Reporting utility. This will be either read-only or read-write as the user specified.

We also allow storage in Magic Data. This is primarily intended for list data that a administrator wishes to maintain centrally in a module and then ship out to regional offices. In addition, the lists stored in Magic Data will be localizable.