Diferencia entre revisiones de «Formularios, secciones y campos»

De Egeasy
Saltar a: navegación, buscar
(→‎Campo)
(→‎Campo)
Línea 83: Línea 83:
  
 
  {{PR|tipo}} [Sí o No] {{PR|es}} {{T|texto}}
 
  {{PR|tipo}} [Sí o No] {{PR|es}} {{T|texto}}
−
-{{AT|apariencia.proporcion}} = 90;
+
    -{{AT|apariencia.proporcion}} = 90;
−
-{{AT|apariencia.desplegable}} = verdadero;
+
    -{{AT|apariencia.desplegable}} = verdadero;
−
-{{AT|edicion.longitud}} = 2;
+
    -{{AT|edicion.longitud}} = 2;
−
        -{{AT|edicion.seleccion}} = verdadero;
+
    -{{AT|edicion.seleccion}} = verdadero;
−
        -{{AT|edicion.valores}} = $matriz({{STR|"Sí"}},{{STR|"No"}};
+
    -{{AT|edicion.valores}} = $matriz({{STR|"Sí"}},{{STR|"No"}};
 
  {{PR|fin}}
 
  {{PR|fin}}
  

Revisión del 11:09 21 ene 2009

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:

Componentes

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á su 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 [MiContenedor] 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 [MiContenedor] 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 MiContenedor, 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, cuyo funcionamiento se puede observar en el artículo dedicado a los escritos.

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 [MiContenedor] 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.

Además de la definición de campo, [Nombre del campo] <code>es tipodecampo</code>, 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
Como habrás observado, 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.

Como 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

Atributos comunes de formularios, secciones y campos

Definiciones de campo

Texto

Entero

Real

Lógico

Moneda

Fecha

Hora

Memo

Imagen

Timbre

Código

Vínculo

Firma

Lista de comprobación

Tabla

Ejemplos

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