Formularios, secciones y campos

De Egeasy
Saltar a: navegación, buscar

En un sistema de información donde intervienen elementos de diferente naturaleza, resulta indispensable ofrecer un mecanismo para la entrada de información que identifique esos elementos. Para ello, ODL facilita al programador una serie de componentes que nos van a permitir diseñar estructuras para la entrada de datos según las necesidades del sistema de información. Estos componentes son formularios, secciones y campos. Veamos a continuación la especificación de cada componente:

Formulario

Un formulario es un componente donde podemos definir secciones y campos. En cuanto a su definición, podemos distinguir dos opciones. La definición de formulario como instancia, o una definición de tipo formulario.

Si definimos un formulario como una instancia tendremos que hacerlo a nivel de contenedores. El compilador no aceptará esta definición fuera de ese ámbito.

Ahora bien, ¿cuándo nos puede interesar una definición de tipo?

A la hora de programar un sistema de información en ODL, es probable que muchos formularios compartan cierto tipo de campos. Para ahorrarnos código, definiremos un tipo formulario con los campos comunes, para luego definir una instancia de ese tipo en la definición de un contenedor o crear nuevos tipos a partir de él. Para entender mejor estos conceptos, veamos la sintaxis de las dos opciones que hemos comentado:
  • Definición de formulario como instancia:
tipo [Mi contenedor] es contenedor
    [Mi formulario] es formulario
        [Campo1] es texto
        ...
        ...
        ...
    fin
fin
  • Definición de tipo de formulario:
tipo [Datos comunes] es formulario
    [Campo común] es texto
    ...
    ...       //Definición de los campos comunes
    ...
fin
Si nos fijamos, la definición de tipo se realiza fuera del ámbito de los contenedores, al contrario que la definición de formulario Mi formulario, que sí se tiene que definir en un contenedor.

Si ahora quisiéramos redefinir Mi formulario como Datos comunes, de manera que se hereden los campos definidos en él, el resultado sería como haberlo implementado de la siguiente manera:

tipo [Mi contenedor] es contenedor
    [Mi formulario] es [Datos comunes]
        [Campo común] es texto
        ...
        ...         //Campos heredados de la definición de tipo "Datos comunes"
        ...
        [Campo1] es texto
        ...
        ...         //Resto de campos ya definidos
        ...
    fin
fin
A la hora de crear un objeto de tipo Mi contenedor, en nuestro formulario aparecerán los campos definidos en Mi formulario y los heredados por Datos comunes. Por tanto, la definición de tipo nos puede servir para crear definiciones de formulario (como en este caso) o para crear nuevos tipos, herendando siempre su contenido.

La definición de tipo no exige la creación de la componente, mientras que la definición de formulario (instancia) sí exige la creación de la componente o del recurso en el que esté definido, en este caso un objeto.

Sección

Una sección es otro componente de ODL que permite agrupar campos dentro de un formulario, diferenciándolos de los demás. Por tanto, se deduce que la definición de una sección se realiza a nivel de formulario. No obstante, también es posible encontrarse definiciones de secciones en un campo tabla, o en definiciones de plantillas.

De igual manera que en los formularios, se pueden realizar definiciones de secciones o definiciones de tipo de secciones. El comportamiento de dichas definiciones es exactamente igual que en el caso de los formularios. En este caso la definición de sección se realizará a nivel de formulario y la definición de tipo de sección la realizaremos fuera de cualquier ámbito.

Veamos por tanto, un ejemplo parecido al del apartado anterior, aprovechándolo también para ver su sintaxis:
  • Definición de una sección:
tipo [Mi contenedor] es contenedor
    [Mi formulario] es formulario
        [Campo1] es texto
        ...
        ...
        [Otros campos] es seccion
            [Campo10] es texto
            ...
            ...
        fin
    fin
fin
  • Definición de tipo de sección:
tipo [Nueva sección] es seccion
    [Campo común1] es texto
    [Campo común2] es texto
    ...
    ...       //Definición de los demás campos agrupados en la sección
    ...
fin

Como vemos, el comportamiento es prácticamente igual que los formularios. Si la sección Otros campos la redefinimos como Nueva sección, la sección Otros campos heredará los campos definidos en Nueva sección.

Campo

Es el componente que se utiliza para la entrada de datos en ODL. Su definición se puede realizar en tareas, tablas de remisiones, tabla de campos y, como ya sabemos, en formularios y secciones.

En cuanto a su definición, además de la definición de campo, [Nombre del campo] es tipodecampo, podemos realizar, al igual que en formularios y secciones, una definición de tipo de campo. Ésta la haremos como código independiente, ya que no se puede realizar una definición de tipo de campo en el dominio antes citado para la definición de campo. La sintaxis de una definicion de tipo de campo sería la siguiente:

tipo [Nombre del campo] es tipodecampo
    -atributo1
    -atributo2
    -atributo3
    ...
fin
En nuestra definición de tipo hemos introducido atributos, que permiten la modificación de ciertos aspectos relacionados con el campo a tratar. Existen atributos genéricos para todos los campos, y otro específicos para cada uno de ellos. En próximos apartados hablaremos de cada uno de ellos y cómo afectan al comportamiento de cada campo.

Como íbamos diciendo, la introducción de atributos es una de las razones por las que nos interese realizar una definición de tipo, ya que a la hora de programar un sistema de información, existen campos que se pueden repetir con frecuencia en muchos formularios, y que incluyen varios atributos. Estos campos repetidos, los declararemos del tipo que hemos definido, de esta manera, nos evitamos tener que incluir todos los atributos tantas veces como definiciones de campo hagamos.

Por ejemplo, imaginemos que tenemos varios formularios dentro de nuestro sistema de información, y que en ellos se realizan preguntas sobre ciertos temas, que requieren un campo de valores "Sí" y "No" proporcionados por una matriz y con un determinado formato. Pues bien, la definición de tipo sería la siguiente: 
tipo [Sí o No] es texto
    -apariencia.proporcion = 90;
    -apariencia.desplegable = verdadero;
    -edicion.longitud = 2;
    -edicion.seleccion = verdadero;
    -edicion.valores = $matriz("Sí","No");
fin

En caso de realizar la definición de tipo, tendríamos que incluir todos los atributos cada vez que definamos ese campo en el formulario. De esta forma, veremos a continuación cómo nos podremos ahorrar muchas líneas de código: 

tipo [Ficha médica] es contenedor
    [Datos] es formulario
        [Nombre] es texto
        [Número de seguridad social] es texto
        ...
        ...
        [¿El paciente es fumador?] es [Sí o No]
        [¿Padece alguna alergia?] es [Sí o No]
        ...
        ...
    fin
fin

Si no hubiéramos definido el tipo, tendríamos que añadir todos los atributos en cada definición del campo, resultando bastante tedioso. Utilizando la definición de tipo se gana, además, en legibilidad del código.

Tipos de campo y sus atributos

En esta sección mostraremos los atributos utilizables en cada tipo de campo:

Propiedades

  • Campo


Atributo Tipo Asignable Observaciones
[&Valor] Texto, entero, real, lógico, hora Sí El tipo devuelto corresponde con el del campo


  • Campo código


Atributo Tipo Asignable Observaciones
[&Rotulo] Texto No Devuelve el rótulo del campo código
[&Valor] Código Sí La asignación de un campo código a otro implica la copia del código y del rótulo.
Si la asignación se realiza a un campo de tipo texto, sólo se copiará el código


  • Campo fecha


Atributo Tipo Asignable Observaciones
[&Dia] Entero No El día correspondiente a la fecha
[&Mes] Entero No El mes correspondiente a la fecha
[&Año] Entero No El año correspondiente a la fecha
[&Valor] Fecha Sí Devuelve el valor del campo fecha. Si se asigna a un campo texto el formato de la fecha es dd/mm/aaaa


  • Campo firma


Atributo Tipo Asignable Observaciones
[&Fecha] Fecha No Día en el cual se realizó la firma
[&Usuario] Texto No Nombre corto del usuario que realizó la firma
[&ID_Usuario] Entero No Identificador del usuario que realizó la firma
[&Sede] Texto No Sede a la que pertenece el usuario que realizó la firma
[&Pie_de_firma] Texto No Delegación de responsabilidad que permitió al usuario realizar la firma
[&Cargo] Fecha No Devuelve el valor del campo fecha. Si se asigna a un campo texto el formato de la fecha es dd/mm/aaaa
[&Valor] Firma No Devuelve el valor del campo firma


  • Campo lista de comprobación


Atributo Tipo Asignable Observaciones
[&Numero_Filas] Entero No Número de filas existentes en la lista de comprobación
[&Numero_Seleccionadas] Entero No Número de filas seleccionadas a verdadero (casilla activada). Si la lista no tiene ninguna fila, devuelve cero
[&Numero_No_Seleccionadas] Entero No Número de filas seleccionadas a falso (casilla desactivada). Si la lista no tiene ninguna fila, devuelve cero


  • Campo moneda


Atributo Tipo Asignable Observaciones
[&Moneda] Texto No Tipo de moneda del campo. Puede ser "euro" o "peseta"
[&Valor] Real Sí Devuelve el importe almacenado en el campo moneda


  • Campo timbre


Atributo Tipo Asignable Observaciones
[&Fecha] Fecha No Día en el cual se realizó el timbrado
[&Usuario] Texto No Nombre corto del usuario que realizó el timbrado
[&ID_Usuario] Entero No Identificador del usuario que realizó el timbrado
[&Sede] Texto No Sede a la que pertenece el usuario que realizó el timbrado
[&Pie_de_firma] Texto No Delegación de responsabilidad que permitió al usuario realizar el timbrado
[&Valor_Secuencia] Texto No El valor de la secuencia
[&Valor_Subsecuencia] Texto No El valor de la subsecuencia
[&Valor] Timbre No Valor completo de la secuencia del timbre


  • Campo vínculo


Atributo Tipo Asignable Observaciones
[&Rotulo] Texto No El rótulo del objeto vinculado
[&Valor_Usuario] Texto No
[&Valor] Entero Sí Identificador del objeto vinculado. Devuelve vacío si no existe vínculo


Atributos comunes de formularios, secciones y campos

A continuación se muestran los atributos que comparten tanto formularios, como secciones y campos. Son atributos no ocultos, es decir, que sus valores son asignables por el programador:


Atributo Tipo Valor por defecto Observaciones
ayuda Texto Marcador en la ayuda del centro.
descripcion Texto [Nombre] Comentario sobre el componente.
etiqueta Texto [Nombre] Etiqueta del componente.
orden Entero 0 Indica la prioridad del componente al ordenarlo sobre el recurso. La componente con el valor más alto, aparecerá más arriba. En el caso de los formularios, la pestaña aparecerá más hacia la izquierda.
visible Lógico Verdadero Indica si el componente es visible o no.


Obtenido de «https://wiki.egeasy.es/index.php?title=Formularios,_secciones_y_campos&oldid=5247»