Diferencia entre revisiones de «Formularios, secciones y campos»

Revisión del 10:24 30 ene 2009 (ver código) Irodriguez (Discusión | contribuciones) (→‎Propiedades) ← Edición anterior		Revisión del 10:27 30 ene 2009 (ver código) Irodriguez (Discusión | contribuciones) (→‎Propiedades) Edición siguiente →
Línea 129:		Línea 129:
	===Propiedades===		===Propiedades===
−	====Campo====	+	===={{T|Campo}}====
	{| style= border="1"		{| style= border="1"
	|-		|-
Línea 142:		Línea 142:
	| El tipo devuelto corresponde con el del campo		| El tipo devuelto corresponde con el del campo
	|}		|}
−	====Campo moneda====	+	====Campo {{T|moneda}}====
	{| style= border="1"		{| style= border="1"
	|-		|-
Línea 160:		Línea 160:
	| Devuelve el importe almacenado en el campo moneda		| Devuelve el importe almacenado en el campo moneda
	|}		|}
−	====Campo fecha====	+	====Campo {{T|fecha}}====
	{| style= border="1"		{| style= border="1"
	|-		|-
Línea 188:		Línea 188:
	| Devuelve el valor del campo fecha. Si se asigna a un campo texto el formato de la fecha es dd/mm/aaaa		| Devuelve el valor del campo fecha. Si se asigna a un campo texto el formato de la fecha es dd/mm/aaaa
	|}		|}
−	====Campo firma====	+	====Campo {{T|firma}}====
	{| style= border="1"		{| style= border="1"
	|-		|-
Línea 232:		Línea 232:
	|}		|}
−	====Campo timbre====	+	====Campo {{T|timbre}}====
	{| style= border="1"		{| style= border="1"
	|-		|-
Línea 280:		Línea 280:
	| Valor completo de la secuencia del timbre		| Valor completo de la secuencia del timbre
	|}		|}
−	====Campo código====	+	====Campo {{T|código}}====
	{| style= border="1"		{| style= border="1"
	|-		|-
Línea 298:		Línea 298:
	| La asignación de un campo código a otro implica la copia del código y del rótulo.<br/>Si la asignación se realiza a un campo de tipo texto, sólo se copiará el código		| La asignación de un campo código a otro implica la copia del código y del rótulo.<br/>Si la asignación se realiza a un campo de tipo texto, sólo se copiará el código
	|}		|}
−	====Campo vínculo====	+	====Campo {{T|vínculo}}====
	{| style= border="1"		{| style= border="1"
	|-		|-
Línea 321:		Línea 321:
	| Identificador del objeto vinculado. Devuelve vacío si no existe vínculo		| Identificador del objeto vinculado. Devuelve vacío si no existe vínculo
	|}		|}
−	====Campo vínculo====	+	====Campo {{T|lista de comprobación====
	{| style= border="1"		{| style= border="1"
	|-		|-

---

Revisión del 10:27 30 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:

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.

Atributos

En esta sección mostraremos los atributos específicos para cada tipo de campo:

• Texto

actualizar_escrito - apariencia.desplegable - apariencia.proporcion - edicion.aspecto - edicion.formato - edicion.longitud - edicion.mensaje - edicion.mensaje_seleccion - edicion.modo - edicion.proteger - edicion.regla - edicion.seleccion - edicion.valor - edicion.valores

• Entero

actualizar_escrito - apariencia.desplegable - apariencia.proporcion - edicion.formato - edicion.longitud - edicion.mensaje - edicion.mensaje_seleccion - edicion.modo - edicion.proteger - edicion.regla - edicion.seleccion - edicion.valor - edicion.valores

• Real

actualizar_escrito, apariencia.desplegable, apariencia.proporcion, edicion.formato, edicion.longitud, edicion.mensaje,

• Lógico
• Moneda
• Fecha
• Hora
• Memo
• Imagen
• Timbre
• Código
• Vínculo
• Firma
• Lista de comprobación
• Tabla

Propiedades

<code>Campo

Propiedad	Tipo	Asignable	Descripción
Valor	Texto, entero, real, lógico, hora	Sí	El tipo devuelto corresponde con el del campo

Campo moneda

Propiedad	Tipo	Asignable	Descripción
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 fecha

Propiedad	Tipo	Asignable	Descripción
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

Propiedad	Tipo	Asignable	Descripción
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 timbre

Propiedad	Tipo	Asignable	Descripción
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 código

Propiedad	Tipo	Asignable	Descripción
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 vínculo

Propiedad	Tipo	Asignable	Descripción
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

Campo {{T|lista de comprobación

Propiedad	Tipo	Asignable	Descripción
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

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.