Forms and Form Classes
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() .
Los Campos y sus Clases
Todos los campos de un formulario tiene un nombre y un tipo. El nombre de los campos es como se referencia el campo por el formulario como una variable pública utilizando los métodos __get() y __set() . Por ejemplo:
if ($person instanceof I2CE_Person) {
echo "$person->firstname . "\n";
}
Los tipos afectan como se guardan los datos en la base de datos y como se muestran los datos y como se introducen en el sistema. La siguiente es una lista de tipos comunes:
- BOOL Un valor Boolean verdadero/falso
- CURRENCY Un valor de moneda
- DATE_HMS Una hora en horas, minutos, segundos
- DATE_MD Una fecha de día y mes
- DATE_TIME Una hora
- DATE_Y Un año
- DATE_YMD Un año, mes y fecha
- INT Un valor entero
- INT_LIST Una lista de enteros
- INT_GENEREATE Un entero que incrementa automaticamente
- STRING_LINE Una línea de texto
- STRING_MLINE Varias líneas de texto
- STRING_PASS Una contraseña
- STRING_TEXT Mucho texto
- YESNO Un valor Si/No
Un $type se maneja por el I2CE_FormField_$type de clase
Los formularios y sus Campos
La estructura de los formularios, sus clases y campos y donde están definidos puede encontrarse fácilmente en:
- Form and Field Browser Aplica para la version de desarrollo 3.2
Como se Guardan los Datos
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.
