Lo primero que tenemos que tener en cuenta es que la clase TRejilla, nos debería proveer la funcionalidad básica para manipular los datos de forma sencilla. Eso es lo que siempre se ha buscado. Así que la clave, en este punto puede estar en valernos de Acciones, que podrán ser asignadas en tiempo de diseño durante la etapa de creación de los módulos de trabajo. Es decir, que nuestro trabajo consistiría básicamente en decidir a tenor de cada uno de ellos, cuales acciones van a quedar disponibles, en la etapa de diseño, sin tener que estar reinventando la rueda continuamente. Esta sería mas o menos la mecánica de trabajo para nosotros a este nivel, durante el desarrollo de nuestra aplicación: Creamos un módulo descendiente de la clase TBrowser, añadimos un componente TRejilla en su interior y ¡voila!, asignamos las acciones que vamos a permitir en aquellos elementos del interfaz que las requieran. Si a este punto añadimos que Ian, hacia formar parte del browser una ToolBar que puede ser receptor de las acciones, el trabajo se simplifica aun mas.

En esta quinta entrada de la serie, tenemos que abordar la clase TRejilla, que como ya comentabamos en las dos entradas previas, iba a servir de enlace entre la rejilla de datos y el formulario de edición (las clases TBrowser y TDialogo).

Vamos a dar otro paso más... En la tercera entrada de esta pequeña serie, nos centrábamos en la clase TAncestro, y pudimos ver como se convertía en la piedra angular del framework de Ian, de la que iba a heredar cualquier tipo de ventana que pudieramos pensar o necesitar. Ian valora en sus ejemplos, dos arquetipos de ventanas diferenciados: el que representa a la clase TBrowser y el que representa a la clase TDialogo. Es su idea, dicho sea de paso, muy razonable, de acuerdo a su experiencia como experto y en ese intento de simplificar. Quizás en vuestro caso, mientras leéis estas lineas imaginéis otros contextos que hagan necesaria la creación de otros descendientes, de acuerdo a criterios mas selectivos, como por ejemplo pudiera ser la seguridad, donde ciertas ventanas pudieran necesitar un tratamiento especial. Nada es descartable y el framework debería ser una propuesta de trabajo que muchos van a adaptarse de acuerdo a sus necesidades. De hecho, os comento que en mi caso concreto y en lo que respecta a la funcionalidad del Framework, descarté algunas partes que no estaba utilizando, como era la posibilidad de arrastrar registros mediante drag&drop, que Ian sí introduce y pone en práctica. Respecto a las ventanas, al final no me fue necesario crear ningún tipo adicional aunque hubiera momentos en los que sí pude habérmelo planteado.

Se podría decir que, al iniciar esta tercera parte de la serie, en la que vamos a razonar sobre el framework de los cursos de Ian Marteens, nos introducimos en una de las areas más bonitas del mismo, donde los razonamientos formales y la abstracción se destacan sobre otros aspectos más mecánicos y menos atractivos (visto ésto como desarrolladores). No se si coincidireis o no, pero no existe demasiado "mérito" en hacer la asignación de una propiedad ni resulta algo demasiado creativo, salvo que lo vivamos desde la perspectiva del creador de componentes. Más bien, forma parte del elenco de actividades repetitivas, que hacemos diariamente de forma mecánica. Sin embargo, en este caso, establecer relaciones de herencia y uso entre las entidades, es un ejercicio estimulante y enriquecedor. Marteens inicia su periplo al definir una clase base (TAncestro), en la cuspide de la jerarquía que define el dominio de la aplicación. Y conviene decir esto ya que TAncestro no nace de la nada puesto que hereda el comportamiento de la clase TForm, de la cual desciende. Lo cual, nos permite disponer de toda la funcionalidad de los formularios que vamos a manipular. ¿Y por que es conveniente que sea así? Pues como bien explica en los primeros parrafos del ejercicio 3 de la serie c :