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.