Introduccion a Developer

Developer (Forms y Reports)

1. Introducción

2. Forms
2.1 Módulo de Formularios
2.1.1 Disparadores
2.1.2 Bloques de datos
2.1.3 Canvas y ventanas
2.1.4 Menús emergentes, avisos, editores, grupos
de registros LOV
2.2 Módulo de Menús

3. Reports

1. Introducción.

Elementos cotidianos del entorno de trabajo de Developer son:

• Formularios.
• Bloques de datos
• Elementos de bloque
• Listas de valores
• Grupos de registros
• Bibliotecas de objetos
• Librerías de código.
• Unidades de programa PL/SQL.
• Módulos de menú
• Módulos de informe
• Modelos de datos
• Composiciones de informes.
• Composiciones de gráficos, etc.
  
  

Las herramientas principales de Developer son:

• Forms.
• Reports.
• Graphics

2. Forms

El componente “Forms Developer” es la herramienta que proporciona el entorno de desarrollo para diseñar:

· Formularios.

· Menús.

· Módulos reutilizables:

- Librerías PL/SQL.

- Bibliotecas de objetos.

2.1 Módulos.

Los formularios son el componente principal de las aplicaciones interactivas. En Forms Developer el modulo es unidad básica de la que se componen los formularios. Los módulos están compuestos de disparadores que los definen funcionalmente, registros de entrada y salida y botones para interactuar con el usuario.

2.1.1 Disparadores.

Un disparador es un bloque de código PL/SQL que se asocia a otro elemento:

• un formulario.
• un bloque de datos.
• un elemento de un bloque de datos.

El disparador se auto ejecuta cuando se da el evento asociado. Pulsar un botón, entrar en el formulario, salir del formulario o meter datos en el formulario son ejemplos de eventos.

Los disparadores contienen PL/SQL pero es más conveniente que ejecuten código de una librería cuando es posible puesto que esto mejora su reusabilidad y la corrección de errores.

Aplicaciones bien diseñadas son aplicaciones con la cantidad menor cantidad de código posible. Es común que, diseños defectuosos o mantenimientos poco estudiados necesiten más código del indispensable.

Los disparadores están definidos en el entorno, cada disparador tiene un nombre específico (por ejemplo, When-Button-Pressed, Post-Query, On-Delete, Key-Help, Pre-Update) que se seleccionar de una lista de nombres de disparador. Los disparadores definen la funcionalidad de la aplicación deshabilitándolos o adaptando su funcionalidad a la necesidad particular de la aplicación.

2.1.2 Bloques de datos.

Un bloque de datos es una colección de registros. Es útil utilizar el asistente para definir los bloques puesto que esto evita muchos errores. Debemos entender un bloque como la correspondencia en Developer de una tabla de la base de datos. Se puede especificar el número de registros que se van a mostrar a la vez y si se van a mostrar horizontal o verticalmente.

Hay dos clases de bloques de datos:

• Un bloque de datos tabla base corresponde a una tabla, vista, procediendo o ref. cursor.
• Un bloque de control no se corresponde a una tabla o vista y sus
  registros no se corresponden a filas de la base de datos.
• Bloques maestro-detalle.

Es útil usar bloques de control para guardar valores únicos o calculados.

El bloque de datos tiene una barra de desplazamiento que permite al
usuario gestionar un conjunto de registros mayor que el que se puede
mostrar en el canvas.

También puede tener un conjunto especial de atributos visuales (elementos programables) que definen un aspecto diferente para el registro en curso, el registro en el que está el cursor.

La navegación dentro del bloque de datos se produce normalmente en el
orden en el que se definen los elementos en un registro. El sistema en
tiempo de ejecución tiene funciones para moverse de elemento a elemento del formulario con los disparadores predefinidos. Cuando el diseño es malo los programadores se ven obligados controlar la navegación dentro del bloque.

Cada elemento de la aplicación tiene unas propiedades. Es conveniente pararse a pensar antes de empezar el desarrollo de una aplicación y definir las propiedades básicas de los elementos. Cada vez que creamos un elemento debemos derivarlo de aquél primero que creamos antes de empezar la aplicación. Si posteriormente tenemos que modificar una propiedad básica, bastará con modificar el elemento base. Esta es la diferencia entre aplicaciones buenas y aplicaciones deficientes en desarrollo.

• Se debe especificar también un formato de máscara en nuestros elementos bases que establezca el formato de la salida o valide la entrada.
• Se debe especificar un valor por defecto
• especificar el nombre de otro elemento del cual copiar el valor inicial.
• Se puede especificar una longitud máxima o el rango de datos, etc

Developer proporciona un asistente de bloques de datos que ayuda a
construir bloques de datos maestro-detallados.

2.1.3 Relaciones.

Una relación es un elemento especial que Forms utiliza para estructurar formularios maestro-detallado.
El elemento relación define la relación del registro maestro con sus registros detallados a través de sus propiedades.
En las propiedades de la relación indicamos las tareas a realizar en case de eliminación de registros maestro.

2.1.4 Canvas y ventanas.

Un canvas es la base sobre la que se sitúa el texto plano y los elementos.

Cada elemento hace referencia a un único canvas en su
hoja de propiedades.

Los elementos de un bloque de datos se pueden dividir entre diferentes canvas.

Un canvas no es un elemento de interfaz autónomo. Para verlo a
él y sus elementos es necesario mostrarlo en una ventana, un
área rectangular rodeada por un marco y mantenida por la
plataforma GUI.

La parte del canvas que se puede ver a través de la ventana es la vista.

La ventana puede tener barras de desplazamiento que permiten moverse a través del canvas para ver diferentes vistas.

Hay cinco tipos de canvas:

• Contenido: muestra el contenido básico de una ventana.
• De fichas: muestra el contenido básico de una ventana en una serie de canvas superpuestos con solapas etiquetadas.
• Apilado: se muestra sobre otros canvas para mostrar información
  condicional o independiente; se puede elegir entre mostrar el canvas apilado cuando se muestre su ventana o dejarlo invisible hasta que se necesite.

Hay dos tipos de ventanas:

• Documento: una ventana que visualiza un elemento “documento” de la aplicación.
• Cuadro de diálogo: una ventana que muestra opciones u otras
  formas de controlar la operativa de la aplicación.
  
  

2.1.4 Menús emergentes, avisos, editores, etc...

Un menú emergente es un menú flotante, que emerge cuando se pulsa con el botón derecho del ratón en un canvas o en un elemento

Un aviso es un cuadro de diálogo especial que muestra un mensaje con un icono y hasta tres botones, como OK y Cancel, Yes y No, etc. Existen tres tipos de avisos:

• Parada.
• Precaución.
• Información.
  
  

Es muy importante definir estos elementos como base antes de empezar a desarrollar y después derivar cada vez que son usados. Es frecuente que una vez comenzado el desarrollo se decidan nuevos diseños y puede ser un infierno buscar todos los avisos y cambiarlos.

Un editor es un cuadro de diálogo con un editor de texto sencillo que permite la introducción de líneas de texto en un elemento texto. El elemento editor permite especificar el tamaño de la ventana, los atributos visuales, el título del editor y otras propiedades de la ventana. Esto permite la creación de editores con apariencias diferentes para diferentes campos de texto.

Un grupo de registros es una estructura de datos especial parecida a una tabla con filas y columnas. Un grupo de registros puede ser un grupo de registros procedentes de una consulta o un grupo de registros estáticos. Los grupos de registros se pueden utilizar en LOV, en parámetros de datos que pasan registros a informes o gráficos, o como estructuras de datos PL/SQL. Es usual que el programador tienda a utilizar grupos estáticos en desarrollos acelerados, esta es la peor solución y conlleva un mantenimiento tedioso.

Un LOV (lista de valores) es un cuadro de diálogo especial que muestra un grupo de registros, permitiendo elegir una fila del grupo, devolviendo un único valor. Un LOV se utiliza como una forma de elegir un conjunto específico de valores.

3. Reports.

La herramienta Reports de Developer es la parte del entorno de desarrollo con la que se realizan los listados.

Un informe puede tener como fuente:

• Consultas externas
• Procedimientos de base de datos.
• Ref. Cursor.

Los componentes básicos de un informe son:

· Modelo de datos.

· Formulario de parámetros (que se envían desde Forms o se introducen).

· Disparadores de informes.

El modelo de datos de informe es la estructura de datos de datos y sus diferentes representaciones en el informe. El modelo de datos se crea en un editor gráfico especial. Diferentes modelos de datos pueden producir el mismo informe de salida. El problema surge los datos almacenados en la base de datos aumenta. Malos desarrollos conllevan tiempos de respuesta bajos y mantenimientos tediosos. Personalmente me he encontrado con informes que tardando días en ejecutarse ha pasado a ejecutarse en segundos modificando su diseño.

Los elementos parámetro son variables a las que se puede hacer se referencia desde el código PL/SQL y cualquier otra cosa que acepte valores de datos como entrada. Hay programadores que utilizan estos valores como variables con la consiguiente inconsistencia funcional que eso conlleva.

Los parámetros del sistema son los parámetros que Reports define automáticamente para controlar el número de páginas, datos mostrados, etc.

Una consulta es una sentencia SQL que devuelve los valores de los datos que son base del informe. La consulta se puede incorporar en un
informe, o se puede utilizar un elemento de consulta externa; éste es
simplemente texto SQL en un archivo independiente que se puede
compartir entre aplicaciones.

En muchas desarrollos se construye el texto de la select en la parte forms y se pasa a report como parámetro. Esta opción, aún posible, no es aconsejable. Muchos programadores y analistas abusan de estan opción y muchos otros copian este modelo de otros diseños invalidos de formularios. Un form ha de pasar solo parámetros a la parte report. En el caso de necesitar reports con querys variables es conveniente elegir otras opciones a la anteriormente descrita como basar los informes en procedimientos almacenados, ref. cursor, texto plano en ficheros… Los parámetros no fueron pensados para esta tarea y tienen un tamaño máximo.

Es conveniente utilizar el asistente lo máximo posible en el desarrollo de reports.

El grupo identifica los registros que devuelven las consultas en el informe como un grupo repetido de registros, existiendo una jerarquía
de grupos.

Las columnas de base de datos son las columnas de la lista SELECT de la consulta.

Las columnas de fórmulas son columnas especiales que se procesan utilizando bloques PL/SQL. Se utilizan para calcular valores.

Las columnas resumen son columnas especiales que acumulan información resumida de múltiples registros en el formulario, tales como subtotales o importes totales.

Las columnas de almacenamiento son columnas que se definen para ser rellenadas con un disparador, una fórmula , en vez de a partir de datos o resúmenes estándar. Por ejemplo se pueden derivar campos especiales de informe que señalen la región con las ventas más altas entre un conjunto de filas regionales.

Los enlaces de datos son enlaces utilizados en informe maestro detallados para enlazar un grupo de filas a otro grupo de filas.

La composición del informe es la estrcutura gráfica del informe. Es muy creativo y muy interesante.

Cada informe tiene una cabecera, un pie de formulario y un cuerpo intercalado entre ellos. Existen diversas variedades de composiciones de informes: tabular, maestro-detallado, formulario, carta, etiqueta de correo, etc.

Los disparadores de informes son bloques de código PL/SQL que se ejecutan en puntos bien definidos: antes del informe, después del informe, entre páginas, antes del formulario de parámetros.

Examenes Oracle

OCP Application Developer Release 2
Curso	Examen
Introduction to Oracle Database, SQL and PL/SQL	1Z0-001
PL/SQL Programming	1Z1-101
Developer 2000: Forms	1Z1-121
Developer 2000: Advanced Forms	1Z1-022
Developer 2000: Reports	1Z1-123