Un día con los mayores (2)

Veamos cual es el siguiente paso…

En este segundo capítulo vamos a para dar un paso más en la construcción del  framework de Ian, creando la estructura del mismo, un esqueleto vacío en el que todavía no vamos a tener en cuenta ni a concretar nada que haga referencia a la lógica real de los datos sino que todavía nos movemos en un nivel abstracto, con acciones que pertenecen al mundo de las ideas como: Guardar, Descartar, Confirmar, etc.

Algunas unidades que van a formar parte de esta estructura, las podéis imaginar como el molde que «ayuda» a un pastelero a que sus figuritas de mazapán sean lo mas similares posibles de una a otra. Ese es el caso de la clase TBrowser y de la clase TDialogo, que van a ser ese molde sobre el que vamos a crear las ventanas que pertencen al interfaz de nuestro usuario.

Y digo intencionalmente «ayuda», ya que en la vida real, la propia lógica de los datos y de las relaciones entre las entidades, hacen que estos esquemas sean simplemente una guía, algo así como esos trajes unitalla, y nos obliga en alguna que otra ocasión a ser, nosotros mismos, quienes tengamos el suficiente sentido comun para que no acaben siendo una celda que nos encorsete y axfisie. Intetaremos, en un momento posterior retomar esta idea y comentarla para que se pueda ver con mas claridad.

Pero vamos a empezar por el principio, como hace Ian Marteens en los primeros capítulos del bloque C del curso. Lo primero de todo es iniciar nuestro proyecto, seleccionando la opción File -> New -> VCL Forms Application – Delphi for Win 32, que creará el nuevo proyecto. Podemos guardarlo con el nombre que queramos. Yo he guardado la unidad de proyecto como «Mayores.dpr» y la unidad principal como UPrincipal, dentro de una estructura de carpetas que he creado para alojar el proyecto.

Cada cual organiza los módulos como cree conveniente y no creo que haya nadie que diga ni que tienes que crearlo todo en una sola carpeta ni que tienes que estructurarlo en cien mil.  Será de esas cosas en las que cada uno tenga su propia opinión. A mi particularmente no me gusta tener un solo directorio por lo que he creado una pequeña estructura.

Una carpeta por ejemplo para todos los archivos que son propios del proyecto y que forman parte del framework. Otra para unidades auxiliares (común) que podrían ser compartidas por otros proyectos por ser recursos de caracter general, como rutinas de evaluación (del dni, de la cuenta bancaria, de cálculo de días de vencimientos en giros, rutinas para saber si un dia cae en festivo o que se yo, si el año es bisiesto y nos trae un dia de mas, etc…).  También podríamos guardar todás las unidades compiladas de nuestro codigo fuente (dcus) en una única carpeta y el ejecutable en otra. Para ello tenemos en las opciones de proyecto donde vamos a activar las rutas que estimemos convenientes. Esta es la imagen:

Y ya que estamos aquí, aprovechando que tenemos el editor de opciones abierto, activaremos el control de versiones. En alguna de las entradas siguientes puede valernos para añadir unas rutinas que nos permitan actualizar de forma sencilla el ejecutable de nuestra aplicación.

Volvemos a nuestra unidad principal, que hemos convenido en llamar UPrincipal.pas, ya que tenemos que cambiar algunas de las propiedades en el inspector de objetos. El estilo de nuestro formulario principal va a ser el correspondiente al de la ventana principal de las aplicaciones MDI, por lo que asiganremos la propiedad FormStyle con el valor fsMDIForm. Ian además, activará las propiedades ShowHint a true y el tamaño de inicio de nuestra aplicación en Maximizado (wsMaximized). Así que procedemos a ello, tras nombrar la unidad siguiendo un patron de eliminar el prefijo «U» que fue usado al guardar (hacemos que la propiedad Name tome el valor de Principal).

Todas estas cosas, estos detalles, no cobran importancia ahora. El que tengamos mas o menos  estructurados los módulos, que asignemos correctamente los nombres de los objetos o dejemos cada cual segun del humor con el que nos alcemos, el que no sigamos patrones para nominar las distintas unidades, el olvidar asociar la adecuada documentación segun la etapa de nuestro desarrollo o simplemente el no realizar los debidos analisis de requerimientos confiando en nuestra experiencia y buena estrella, puede ser algo banal o puede ser una soga que se ate a nuestro cuello desde los primeros pasos del mismo.  🙂

Más adelante, vamos a necesitar al menos dos módulos de datos. No vamos a crear ahora mismo los componentes que formaran parte de los mismos y que nos permitirán conectarnos a la fuente de datos. Simplemente, añadimos un módulo de datos (datamodule) para la capa cliente, que llamaremos «UDatos.pas» y otro para el conjunto de datos que accedera a nuestro servidor, «USQLDatos.pas».

Es decir, hacemos File -> New -> Other -> [Delphi Project -> Delphi Files -> Data Module]

Asi que en este punto ya tenemos casi todo… 🙂   ¡Qué más quisierais!

¡No, si yo tampoco me lo creo! 🙂  No hemos hecho más que comenzar. Tenemos una archivo de proyecto, una unidad principal que va a responder al esquema de aplicaciones mdi y dos modulos de datos. Y TIENEN QUE EJECUTARSE EN UN ORDEN YA DETERMINADO. Primero la unidad que nos va a permitir conectar con la fuente de datos (USQLDatos.pas). Luego el modulo de datos (TDatamodule) que representa la conexion del cliente (UDatos.pas) y finalmente, el interfaz, nuestra ventana principal, que tendra una relación de «amistad» o «conocimiento» con UDatos, ya que se vale de el para acceder a las distintas peticiones de nuestro usuario.

Esto tiene un sentido que no es dificil de comprender. Tened en cuenta que no estamos separando las capas y que tanto el acceso a los datos del servidor como el que representa al cliente, forman parte de la misma aplicación, dentro de lo que pudiera ser el modelo que representa tradicionalmente a la arquitectura cliente-servidor. En un desarrollo multicapa, el modulo que puede dar servicio al acceso a datos estaría escuchando en algun punto accesible a la aplicación cliente y serviria de intermediario entre esta y el servidor. Por tal razón respetamos el orden y crearemos los distintos módulos según ese esquema. Y van a existir durante toda la vida de nuestra aplicación.

Veamos como quedan dentro de las opciones del proyecto:

Hemos dicho que nuestra aplicación va a responder al modelo MDI y realmente no hemos dicho demasiado sobre ello. No se decir si me gusta mas o menos, pero sí es cierto que tiene algunas pequeñas ventajas que pueden ser resaltadas. Una aplicacion SDI se organiza mediante ventanas que ocupan un espacio no determinado sobre el escritorio y aunque sigue existiendo una ventana principal esta puede llegar a ser ocultada por el resto de ventanas que se crean en tiempo de ejecución. Así que puede hacerse necesario que controlemos la posición y el tamaño de las mismas. En el modelo MDI, la ventana madre o principal siempre queda visible cuando está activa (una preocupación menos que nos la resuelve el propio sistema)l, y organiza en su interior las ventanas «hijas» creadas. Todos conocemos de sobra esos modelos porque lo hemos vivido con Delphi tanto uno como el otro. El modelo mdi facilita o nos permite desprecuparnos sobre detalles como la posición de las ventanas hijas (en este caso más aun ya que siempre es creada maximizada), permite organizarlas y acceder a ellas facilmente.

En el framework de Ian Marteens, las ventanas hijas, representarán la búsqueda inicial del usuario, y se plasmarán sobre una rejilla que mostrará el resultado de la misma.Inicialmente, puede estar vacía de datos (es lo que recomienda Ian con muchos sentido común) y la elección del usuario sobre los parametros de busqueda, crea el conjunto de registros con los que trabajará en ese momento nuestro usuario. El framework le permitiría saltar de una ventana a otra, de clientes a proveedores, de facturas a pedidos hasta que se decide editar o insertar (manipular datos), momento en el que va a participar una ventana modal que va a contener los datos del registro que ha seleccionado el usuario. Esta ventana modal tendría el estilo de ventana «fsNormal» y sería descendiente de la clase TDialogo, que ya ha sido nombrada en lineas superiores.

Hay desarrolladores que no son partidarios de los enfoques modales en la edición de las fichas. Yo veo que es una solución muy práctica, que te da un mejor control sobre el proceso de edición. Sin embargo, se podrían poner algunos «peros» que pueden ir apareciendo a medida que se desarrolla nuestro proyecto y que tienen que ver con los prerrequisitos que la garantizan y que pueden necesitar adicionales ventanas modales para satisfacerlos. ¿Cual es la cantidad máxima que nos vamos a permitir? ¿O bien relajamos las condiciones y nos valemos de un trigger para elaborar algunos procesos que puedan ser necesarios previamente? ¿Obligo a crear el artículo previo a la edición del documento de venta,  le doy la opción de crearlo en ese momento o postergo la creación al disparo del trigger, una vez grabado el registro?  Son temas que no siempre resultan sencillos ya que la decisión puede depender de otros factores ajenos a la propia aplicación.

En la tercera parte del framework, vamos a meternos en harina y disfrutar de los razonamientos que se descubren en las relaciones de herencia entre las clases TAncestro, TBrowser y TDialogo. Lo vamos a ver ya, en nada, a la vuenta de dos o tres días (si en ese tiempo no me atacan los indios de nuevo el servidor).  😉

Es muy tarde. Las dos y cucu… En fin. Tengo que descansar.

Ahhh Para acabar, olvidaba poner la dirección de los cursos de Ian Marteens por si alguno puede estar interesado. En mi opinión, y aunque el contenido ahora mismo no este actualizado con la última versión de nuestros entornos, la metodologia que utliza trasciende a una versión concreta. Somos muchos los programadores de Delphi que hemos aprendido en las páginas de sus libros, ya que no tienen desperdicio.

Nosotros solo vamos a ver un pequeñisimo extracto del framework por lo que, podeis acceder en este link si deseais mas información sobre los mismos.

http://www.intsight.com/training.html