En esta quinta parte 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). La idea es que la sexta parte de por finalizada la serie, con independencia de que en un momento posterior encontremos tiempo para compartir comentarios que puedan ser interesantes. Nos estamos acercando al final.

Recordad las imagenes que mostraban las relaciones entre las clases y que compartiamos en la entrada tercera.

La primera imagen nos hablaba de las relaciones de herencia entre TAncestro, TBrowser y TDialogo.

La segunda, las relaciones de uso entre TBrowser, TDialogo y TRejilla.

En esa segunda imagen, se puede ver que existe (o puede existir *) una relación de uso, que es lo que realmente queríamos remarcar. Sin embargo, ésto expresado así, os podría inducir a error, ya que si tomamos el concepto expresado en dicha imagen literalmente, vendría a expresar que las clases TBrowser o TDialogo se componen de una rejilla, o dicho de otra forma, que contienen en su interior una instancia de la clase. Y realmente, la imagen era meramente descriptiva de la relación. En nuestro caso, únicamente serán los descendientes de TBrowser o de TDialogo, quienes podrán contenerlas, ya que de no ser así nos ataríamos a un esquema de trabajo demasiado rígido.

(*) Aunque el ejercicio 13 que contiene el framework de Marteens no contiene  descendientes de TDialogo que hagan uso del componente TRejilla, comentabamos que es factible de ser usado, ya que pueden existir detalles que dependan de los detalles del dataset maestro. Si recordáis la primera entrada, en ella existía una imagen de la aplicación en ejecución, donde se podía ver en el interior de la ventana que representa la ficha del beneficiario, un detalle de suscripciones que se resuelve con la ficha de edición de suscripciones y que a su vez contiene la rejilla de asistencias. Esta era la imagen.

Para lo que pueden sentirse perdidos a estas alturas, estamos presentando sobre nuestra mesa de trabajo las distintas piezas que van a participar en el framework de Ian Marteens, para, una vez hecha la presentación,  abordar de forma global la puesta en marcha de todo el conjunto, tarea que seria abordada en una ultima entrada (la sexta y definitiva). El ejemplo que ha dado sentido a la serie debería, en teoría, ser razonado desde el puzzle que tenemos en nuestras manos.

Recapitulemos...

En estos momentos, nuestra aplicación debería contener el módulo principal (UPrincipal.pas), dos datamodules (UDatos.pas y USQLDatos.pas) que pueden estar creados pero que todavía no contienen ningún componente, ya que si recordáis lo comentado en la entrada 2, esa parte la íbamos a abordar al hacer referencia a Datasnap, dentro de la puesta en marcha del framework.

Tambien deberíamos haber generado el modulo UAncestro.pas, conteniendo la clase base, de acuerdo a las indicaciones de la tercera parte de la serie. Y finalmente, añadiendo a nuestro proyecto UBrowser.pas y UDialogo.pas respectivamente, creados ambos tomando como ascendente la clase TAncestro, ubicada en la unidad UAncestro.pas.

Aunque en aquellos momentos no concretamos nada, es un paso sencillo. Para ello, bastaba ir al menú principal del entorno y hacer

File -> New -> Other, seleccionando la unidad deseada, en nuestro caso TAncestro.

Y una vez creadas ambas unidades (UBrowser.pas y UDialogo.pas), añadir el contenido razonado en Un día con los mayores (4) para cada una de ellas. La simple inspección ocular del código nos indica que TBrowser contiene en su interior una TToolBar, que en un futuro habilitaría las distintas acciones disponibles del conjunto de datos (insertar, eliminar, editar, buscar, etc...). TDialogo, por el contrario solo necesita un par de botones para aceptar y cancelar la edición (la pulsación del primero debería producir el valor mrOk, mientras que el segundo haría lo propio con el valor mrCancel) y un groupbox (TGroupBox) incluido tan solo para contener los distintos controles de datos agrupados.

Ahora ya podemos proseguir...

Vamos a crear la unidad URejillla.pas, que contendrá el componente TRejilla. Accedemos al menú del entorno.

File -> New -> Delphi Files, seleccionando la unidad deseada, en nuestro caso Frame.

Al aceptar el experto, vamos a obtener un módulo que contiene el contenido mínimo y que incluye la declaración de tipos del descendiente de TFrame.

PLAIN TEXT
DELPHI:




unit Unit1;


interface


uses


Windows, Messages, SysUtils, Variants, Classes, Graphics,


Controls, Forms, Dialogs;


type


 TFrame1 = class(TFrame)


 private


  { Private declarations }


 public


  { Public declarations }


end;


implementation


{$R *.dfm}


end. 

Asignamos las propiedades Name del componente para que tome el valor Rejilla y guardamos la unidad con el nombre propuesto (URejilla.pas).

Nos resta tan solo añadir el contenido a nuestro Frame y para ello, podemos hacerlo en tiempo de diseño (una de las ventajas, entre otras, que sin duda inclinaría a Ian Marteens a elegirlo como contenedor base del componente).

Veamos que incluye Ian en el:

Lo mas importante es la rejilla de datos (TDBGrid) ya conocida por todos ya que  nos ha acompañado desde siempre. También vamos a añadir un datasource. La rejilla se conectará al mismo a través de la propiedad DataSet, como se puede suponer. El tercero en discordia es el componente TActionList, al que podemos ya añadir las acciones predefinidas para gestión de Datos, ligadas de igual forma al datasource. Y finalmente, nos resta añadir un componente Tpopupmenu, que puede asignarse a la propiedad PopupMenu del DBGrid y contener las acciones deseadas del componente contenedor de las acciones.

Esta podría ser una imagen de nuestro Frame, tras seguir los pasos comentados. He incluido en la imagen los nombres junto a cada uno de ellos.

Y en las dos siguientes imágenes, podéis apreciar el contenido del contenedor de acciones y del popupmenu. Así queda un poco mas claro.

Permitid me un comentario al hilo de la imagen que muestra el contenido de TRejilla.  Es algo que ya hemos recalcado desde el principio: En la primera de estas 3 imágenes, existen dos componentes que se encuentran tachados. Los he dejado a la vista, porque originalmente, el framework de Marteens, incorpora una buena cantidad de detalles que solo tienen sentido dentro de un cursos tan ambiciosos como cualquiera de los planteados por el. Desgraciadamente en el ámbito de estas entradas, que son tan breves, es imposible no recortar el contenido, mas cuando la filosofía que las ha generado es simplemente la de compartir una experiencia de uso del mismo. En el framework se implementa un mecanismo sencillo y muy didáctico de selección de búsquedas que simplificaremos al máximo (de ahí que se haya excluido el componente sobre el que se centra la acción, que es el popupmenu tachado). La impresora en cambio, representa el dialogo de impresión, funcionalidad a la que previamente habíamos renunciado por el mismo motivo. Y, aunque aquí no van a aparecer, dentro del código fuente, también se implementa los procedimientos que permitirán que las rejillas sean capaces de implementar la funcionalidad de drag&drop, de forma transparente para el proceso posterior de montaje de la aplicación.

No obstante, el código que resta es muy interesante, como creo que al final coincidiréis.

El por qué ha elegido Ian Marteens la clase TFrame como clase contenedora es la primera reflexión que nos podríamos plantear ya que TRejilla también podría haber sido creada partiendo de otro ascendiente. Existen numerosas clases que tienen esta funcionalidad de albergar componentes en su interior (se me ocurre TPanel por ejemplo) pero a diferencia de ellas, no podríamos diseñar ni formaría parte del repositorio de objetos, con la flexibilidad y potencia que ésto nos puede aportar. Ese punto es vital. Es mas, el planteamiento aprovecha al máximo todo lo bueno que puede darnos la clase TFrame, ya que no siempre resulta "fácil" su uso en planteamientos que impliquen la creación dinámica de los mismos y los accesos en tiempo de ejecución a los componentes que lo componen y que dotan la funcionalidad deseada. Un ejemplo de este tipo de uso podría ser frameworks similares al compartido por nosotros en aquella entrada titulada Un enfoque modular para nuestra aplicación. Si habéis leído la serie que se publicó en los Boletines 13, 14, 15 y 16 del Rinconcito de Delphi creo que entenderéis a que hago referencia.

Es mas... antes de meternos de lleno en el código, permitirme por favor otro alto en este figurado camino. Permitid que os dirija a la siguiente página dentro de la web del escritor:

http://www.marteens.com/trick46.htm

En ella se habla de un concepto conocido como "interponer una clase", que resulta extremadamente útil en este contexto como forma práctica y eficaz de extender la funcionalidad de los componentes sin tener que hacer instalaciones en el entorno. Leedla con tranquilidad porque es muy interesante y no tiene desperdicio. Marteens también se vale de esta técnica al abordar su curso y la aplica en varias ocasiones. En este caso concreto, es usada para cambiar el comportamiento del componente DBGrid contenido en la rejilla, de forma que todos los módulos que hagan uso de ella y declaran UGrids tras la unidad Grids de la VCL, redefinen su comportamiento. Así de práctico y de sencillo.

El motivo que le lleva a considerar su uso es dotar al componente DBGrid de persistencia (las dimensiones de sus columnas son recordadas en tiempo de ejecución permitiendo de forma transparente que sea configurada a gusto de nuestro usuario), permitir la ordenación de los campos tras hacer click sobre las cabeceras de cada columna, drag&drop a nivel de registro y finalmente, y la que me parece particulamente clave, que es sobrescribir el procedimiento virtual que afecta al doble click para que la rejila pueda dar tratamiento a la edición del formulario.

Extraemos un fragmento de la unidad incorporando únicamente los aspectos relacionados con la ordenación y con el procedimiento DblClick.

El evento OnDblClick de la rejilla sigue así estando disponible para su uso y se disparará siempre previo al envío del mensaje.

En el mundo real, me resultó de ayuda añadir un mensaje adicional

CM_EVENTOMOSTRAR = WM_USER + 2;

que pudiera ser entregado tras la creación del formulario modal a la ventana browser que generaba la llamada, ya que aunque sí podía redefinir las acciones en el descendiente al insertar o modificar, no resultaba tan sencillo capturar el doble click, oculto por el componente TRejilla, que le daba tratamiento tras el envío del mensaje por el componente DBGrid. Dado que en el contexto de ejecución que activa el doble click, la ventana activa seguía siendo el formulario browser, no era demasiado complicado añadir un mensaje que pudiera ser tratado por este según nuestra necesidad. 

procedure TDBGrid.DblClick;
begin
  inherited DblClick;
  if Assigned(Parent) and Parent.HandleAllocated then begin
    PostMessage(Parent.Handle, CM_MOSTRAREDITOR, 0, 0);
    PostMessage(Screen.ActiveForm.Handle, CM_EVENTOMOSTRAR, 0, 0);
  end;
end;

Otras veces, pensé que podría ser me de interés la creación de un evento previo y posterior a la comunicacion de los mensajes. En tales casos, escribía la implementación:

procedure TRejilla.CMMostrarEditor(var M: TMessage);
begin
  //antes de gestionar el mensaje
  if Assigned(FOnBeforeOpenEditor) then FOnBeforeOpenEditor(Self);
  if Assigned(dsBase.DataSet) then
    if dsBase.DataSet.IsEmpty then
      DataSetInsert.Execute
    else
      DataSetUpdate.Execute;
  //despues de gestionar el mensaje
  if Assigned(FOnCloseEditor) then FOnCloseEditor(Self);
end;

añadiendo en la parte publica de TRejilla, las propiedades respectivas:

    property OnBeforeOpenEditor: TNotifyEvent read FOnBeforeOpenEditor write SetOnBeforeOpenEditor;
    property OnCloseEditor: TNotifyEvent read FOnCloseEditor write SetOnCloseEditor;

Lo cual me daba la posibilidad de implementar una respuesta desde el formulario de navegación.

Ahora ya estamos en condiciones de poder abordar el código y resaltar los puntos claves que nos permitirán comprenderlo.

Lineas mas abajo podemos ver un extracto del interfaz y la declaración de tipos. Tras la sección correspondiente a los "uses", que hacen referencia a unidades enlazadas, es declarada la interfaz IManipulacionDatos, que concentra lo que pueden ser las tres acciones básicas de manipulación de datos: la inserción, el borrado y la modificación. Un poco mas abajo, TGeneradorSQL, permite de forma generica establecer la que será la cadena SQL que abre la consulta de nuestra rejilla de datos. Declararla de esta forma, nos obliga a que el proveedor establezca dentro de sus opciones poAllowCommandText, pero nos abre un abanico grande de posibilidades, tanto de forma dínamica que es como Marteens establece las busquedas o bien, estática, que es como de forma sencilla nos la plantearemos nosotros. Finalmente, es declarado el tipo TRejilla.

¿Qué papel juega cada elemento?

Solo voy a comentar ahora, que la propiedad publica Editor, es la que nos permite establecer una relación entre la ventana de navegación y la de edición modal. Al hacer doble click sobre el componente TRejilla o ejecutar las acciones de edición o inserción, finalmente llegaríamos a una linea de codigo

FEditor.Ejecutar(Owner) = mrOk;

que se resolvería en el ancestro de nuestra ventana de dialogo. La ejecución del metodo de clase Ejecutar lanzaría la edición de la ficha.

class function TAncestro.Ejecutar(AOwner: TComponent): TModalResult;
begin
  if AOwner = nil then
    AOwner := Application.MainForm;
  with Create(AOwner) do
  try
//    RegistroLeer;
    Result := ShowModal;
  finally
    Free;
  end;
end; 

En muchas ocasiones he intentado compartir con vosotros, a lo largo de las entradas del blog, puntos en los que la ganancia de pensar en clases y de usar la herencia nos permitían llegar un poco mas alla de las meras asignaciones, y estas lineas que nos permiten compartir el framework de Ian, responden con creces a esta idea.     

Lo dejamos aquí.

Os dejo con la intriga...

En la parte B de esta quinta entrega abordamos la implementación y nos quedaria la sexta y final, en la que vamos a intentar armar el puzzle para que las piezas encajen. 

Espero que estas entradas os puedan servir de algo y que os ayuden. Y como hago en cada una de ellas, os animo a recabar mas información sobre los cursos de Ian, en el enlace a su web, que también figura en la sección de enlaces de la barra lateral del blog.

http://www.marteens.com/

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.

En el caso que nos ocupa existe un primer tipo, necesario para mostrar aquellos registros que el usuario demandará, de acuerdo a ciertos criterios no siempre sabidos de antemano. La idea es mostrar solo lo que el usuario necesita. El sentido común debería prevalecer siempre para seleccionar qué datos son los que realmente va a necesitar nuestro usuario, que por sistema demandará "todo". Es razonable darle lo que realmente necesita ¿no os parece?. Mi padre siempre me recordaba un refrán que decía que contra el vicio de pedir estaba la virtud de no dar.

También debería ser razonable (y ciertamente también discutible) que la ventana que va a mostrar los distintos registros no devolviera inicialmente ninguno y que fuera el usuario quien nos dijera que va a necesitar. Bueno... a nosotros no... me refiero a la aplicación. Marteens muestra un sistema muy sencillo de búsquedas que van a permitir que el usuario, mediante una elección, pueda satisfacer esa demanda de información.

De todo esto, y como resumen, queda la idea de que nuestro primer tipo, la clase TBrowser, va a servir para explorar los datos, permitirá navegar sobre esta información (algo usual en estas aplicaciones) y que nuestro usuario pueda también sobre ellos ejecutar determinados procesos en aras de "determinados" resultados. Cualquier caso que se nos ocurra puede ser oportuno: la lista de clientes que mas nos han comprado de cada provincia, aquellos que pertenecen a una provincia concreta,  etc. Habitualmente pretenderá acciones conocidas por todos, como borrar, modificar o insertar, pero bien nos puede valer para extender a procesos que puedan recaer no ya sobre un registro concreto sino una colección de ellos. Esa es un poco la idea que justifica y da vida a la clase TBrowser.

Recordemos una imagen de la ventana, en la que existía un componente contenedor de acciones TActionList y una barra de botones TToolBar, que mostrará visualmente las distintas acciones disponibles para el conjunto de datos mostrados al usuario.

Esta es la imagen:

A continuación, mostramos el código, que realmente no va a extender el comportamiento de TAncestro, mas en la capacidad para imprimir el contenido de la información que mostrará la ventana. Todas estas lineas realmente son opcionales.

Ved el código que ha implementado Ian y comentamos:

Llegado este punto y dado que hemos utilizado la referencia en el uses a la unidad UImpresion, deberíamos también darle un mínimo de contenido para seguir adelante, con independencia de que no comentemos la implementación concreta que ha sido utilizada para imprimir los registros, puesto que esto es algo que podemos concretar de acuerdo a nuestras necesidades.

Como mínimo debería contener:

PLAIN TEXT
DELPHI:




unit UImpresion;


 


interface


 


uses Classes, SysUtils, Graphics, Printers, DB, DBGrids;


 


type


  IImprimible = interface


  ['{267E5074-DF76-4ACE-ACCB-2BA6831F193A}']


    procedure Imprimir;


  end;


... 

Marteens se apoya y desarrolla una función con ambito global al modulo, con esta firma:

function CreateReport(const ATitle: string; AGrid: TDBGrid): IInforme;

que va a ser llamada por aquellos objetos creados que hagan uso del interfaz IImprimible, dando respuesta al contrato que concluye el procedimiento Imprimir.

Vosotros podéis crear vuestra propia función, pero debéis de tener en cuenta algo muy importante y es que para este nivel de abstracción, no conocéis que campos concretos van a existir y debéis actuar siempre bajo esa premisa...  Debería ser una función que en muchos puntos, lógicamente recorrerá estructuras apoyándose en las propiedades especificas para delimitar los dominios de las mismas. Un ejemplo para verlo con mas claridad: Podría ser una rejilla el objeto de nuestra atención y podría también ser la estructura genérica de columnas que contiene la rejilla, la que nos permitiera descubrir los distintos campos del informe. La propiedad Count de la clase TColumn, mantiene el total de columnas existentes en la matriz y cualquier bucle típico (for do, while do, etc..) recorrerá la matriz y nos permitirá acceder a la información deseada.

El como se monte este código es un tanto lo de menos. Ian simplifica al máximo y crea un informe genérico que nos pueda valer para cualquier rejilla que muestre datos al usuario. De esa forma, economizamos nuestro esfuerzo y nos despreocupamos de este tipo de detalles que suelen ser bastante ingratos y absurdos.

En la declaración de tipos anterior, nos aparece la declaración de la interfaz IImprimible, que consta de un único procedimiento, acompañada del CLSID o GUID, propios de una interfaz COM.

Volviendo a la idea comentada,  yo acabé añadiendo unas rutinas que permitían exportar a Excel el contenido de cualquier información mostrada por las ventanas descendientes de TBrowser. ¿Qué tal crear otra interfaz IExportable, tal que pudiera considerar esta opción? Son decisiones que van a depender de vuestro contexto de trabajo para valorar que pueda ser necesarias o no lo sean. En cualquier caso, no resulta demasiado difícil descubrir que existen colgando de la red de redes distintas implementaciones que hagan precisamente esto. Así que pudiera ser una buena excusa para dar un vistazo y ver si puede ser usada para nuestro fin.

No perder de vista la implementación del método Imprimir que hace TBrowser. Este punto es clave.

  for I := 0 to ControlCount - 1 do
    if Supports(Controls[I], IImprimible, Imp) then
    begin
      Imp.Imprimir;
      Exit;
    end;

Cumplimos nuestro contrato y además delegamos la impresión en cualquier objeto que soporte la interfaz IImprimible, contenido en nuestra instancia descendiente de TBrowser. Lógicamente hacemos algo de trampa. Nosotros no... Ian, que es mas pillo que bonico, que dirían en mi pueblo...   porque estamos suponiendo que solo existe un objeto que implemente la interfaz. Pero es nuestro supuesto y partimos de que no va a existir mas de una rejilla en cada explorador de datos. ¿Podría darse el caso de que nuestro explorador de datos tuviera un maestro y un detalle? Son cosas que nadie lo sabe salvo el desarrollador que tiene entre manos el proyecto y estudia el interfaz adecuado a esa información.

Supports, es una función implementada en el modulo SysUtils que nos permitirá saber si el objeto (en este caso concreto representado por la matriz Controls[I]), usa el contrato, permitiendo referenciar en la variable Imp de tipo IImprimible (del tipo de nuestra interfaz) una forma de acceder a la instancia y ejecutar el método en cuestión.

Si el control no declara la interfaz en alguno de sus ascendientes o en él mismo, la función lo ignorará. Si encuentra alguno, no buscará mas.

Y respecto a la segunda unidad, tampoco el código es excesivo. Esta es la imagen de la ventana que representa a TDialogo y el código presente en el módulo usado por Ian en el curso:

PLAIN TEXT
DELPHI:




unit UDialogo;


 


interface


 


uses


  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,


  Dialogs, UAncestro, DB, DBClient, StdCtrls, ActnList, ImgList;


 


type


  TDialogoClass = class of TDialogo;


 


  TDialogo = class(TAncestro)


    dsBase: TDataSource;


    BasePanel: TGroupBox;


    bnOK: TButton;


    bnCancel: TButton;


    procedure FormKeyPress(Sender: TObject; var Key: Char);


  protected


    function Modificado: Boolean; override;


    procedure Guardar; override;


    procedure Descartar; override;


  end;


 


implementation


 


{$R *.dfm}


 


{ TDialogo }


 


function TDialogo.Modificado: Boolean;


begin


  if not Assigned(dsBase.DataSet) then


    Result := False


  else


    with dsBase.DataSet as TClientDataSet do


      if Assigned(DataSetField) then


        Result := Modified


      else


        Result := Modified or (ChangeCount> 0);


end;


 


procedure TDialogo.FormKeyPress(Sender: TObject; var Key: Char);


begin


  inherited;


  if (Key = #13) then


  begin


    Perform(WM_NEXTDLGCTL, 0, 0);


    Key := #0;


  end;


end;


 


procedure TDialogo.Guardar;


begin


  if Assigned(dsBase.DataSet) then


    with dsBase.DataSet as TClientDataSet do


      if Assigned(DataSetField) then


        CheckBrowseMode


      else if ApplyUpdates(0)> 0 then


        Abort;


end;


 


procedure TDialogo.Descartar;


begin


  if Assigned(dsBase.DataSet) then


    with dsBase.DataSet as TClientDataSet do


      if Assigned(DataSetField) then


        Cancel


      else


        CancelUpdates;


end;


 


end. 

Este segundo tipo de ventana, responde a la edicion/inserción de datos de nuestro explorador, representado como ya hemos comentado por la clase TBrowser. El usuario seleccionará uno de los registros, y esta ventana (TDialogo), nos permitirá recoger esos cambios.

Marteens nos hace una propuesta donde TDialogo es modal. La pregunta sobre la bondad o maldad de ser así ya es otro cantar. Yo también encuentro mas sencillo este esquema, que trabajar sobre el supuesto de un formulario no modal. De hecho, no me he planteado para este tipo de aplicación un esquema distinto puesto que funciona bien, ya que le permites a tu usuario libertad a nivel del explorador de datos con la única condición de que concluya las operaciones. ¡No todo van a ser ventajas para nuestro usuario mimado. Lo cual, introduce cierta inquietud sobre el hecho mismo de considerar que puedan no existir las condiciones necesarias para que concluya el proceso de edición con éxito, lo cual suele ser salvado mayormente creando ventanas auxiliares que favorezcan cumplir esas condiciones. Pero claro... tiene que existir un limite en esa recurrencia.

Originalmente el curso trae los procedimientos Modificado, Guardar y Descartar, que eran tres de las acciones abstractas, ya comentadas en la entrada anterior. Creo recordar que cansado de añadir la implementación del evento OnKeyPress de cada formulario, acabé escribiendo la rutina con la idea de asignarla en el descendiente si me era necesario.

Respecto a los tres procedimientos, quizás lo veáis mas claro pensando que pueda ir ligada su invocación sobre una fuente de datos que apunta al registro maestro o haga referencia a uno de sus detalles. Dado que no sabe a ciertas, desde este punto el origen de la llamada, no puede mas que prevenir que sea el ClientDataSet que soporta la acción (representado en dsBase.DataSet) sea el maestro de datos, en cuyo caso no tendría asignado el campo DataSetField. De ser al contrario, si dsBse.DataSet apunta a una fuente de datos que representa un detalle del registro maestro, existiría esta asignación. Marteens actua en consecuencia. En este punto quizás podría seros util recordar una entrada que compartimos tiempo atrás y que hablaba de esto precisamente:

(Entradas: Por curiosidad I, II y III) http://sjover.com/delphi/?p=128 ,  http://sjover.com/delphi/?p=129 y http://sjover.com/delphi/?p=130

En los tres casos, Modificado, Guardar y Descartar hacen cosas distintas según el caso. Intentaremos comentar esto con mas detalle cuando abordemos la parte que hace referencia a datasnap.

Espero que estas entradas os puedan servir de algo y que os ayuden. Y como hago en cada una de ellas, os animo a recabar mas información sobre los cursos de Ian, en el enlace a su web, que también figura en la sección de enlaces de la barra lateral del blog.

http://www.marteens.com/

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 :

"A partir de determinado tamaño de aplicación, se hace necesario organizar las ventanas de un proyecto de acuerdo a una jerarquia de herencia. El principal motivo es evitar tareas repetitivas cada vez que se añade una nueva ventana durante el desarrollo. Pero una vez que ya existen las ventanas prototipos, existen ventajas innegables para el mantenimiento de las mismas."

La palabra clave aquí es Prototipo. Esa es la clave con la que deberiais quedaros. Es decir, buscamos prototipos que simplifiquen los procesos de creación de entidades, que permitan gastar el mismo esfuerzo en el proceso de construcción, a todos los niveles. No reinventar la rueda en cada nuevo formulario en todo aquello que va a ser comun a todos. Sí. Estoy seguro de que la mayoría coincidirá en esto, aunque luego el día a día, haga que no siempre podamos avanzar afianzando la base del edificio y tengamos que conformarnos en dar una mayor altura al mismo, limitandonos a constuir un piso mas.

Pero lo mejor, es verlo con dos imagenes en las que se muestran dos de las relaciones tradicionales que se pueden establecer entre distintas entidades: "es una" y "usa una". Una relación de herencia y otra de uso. En las imagenes van a aparecer las clases claves dentro de la estructura del framework y nos permitiran tener una visión global y amplia del mismo.

Relaciones de Herencia entre TAncestro, TBrowser y TDialogo.

Relaciones de Uso entre TBrowser y TRejilla.

Sobre la primera imagen, se definen las relaciones de herencia entre TAncestro y TDialogo, y TAncestro y TBrowser. En ambos casos, TAncestro es el ascendente de ambas clases, que servirán a su vez como ascendente de aquellas ya especificas de cada modulo. Mientras los descendientes de TBrowser nos ayudarán a seleccionar aquellos registros que van a ser requeridos por el usuario (valiendose de una instancia de TRejilla), los descendientes de TDialogo serán figuradamente la ficha sobre la que vamos a editar.

Sobre la última imagen, es obligado hacer un pequeña reflexión puesto que en la misma, puede verse en la parte izquierda como se ha colado sobre un recuadro definido por una linea verde, la clase TDialogo. Se ha colado de puntillas porque fijaos que el título que hemos utilizado es "Relaciones de Uso entre TBrowser y TRejilla" y de hecho, esta relacion entre TDialogo y TRejilla, no aparece expresamente definida en el curso de Marteens (o al menos no la he encontrado ni la recuerdo en estos momentos). Tampoco preocuparos demasiado si ahora mismo no lo veis porque mas adelante debería aparecer esta situación (la ficha de beneficiarios tenía direcciones y tambien suscripciones a actividades si recordais el esquema de nuestra bbdd). Serán necesarios unos pequeños cambios.

Siendo como es TRejilla, una clase especializada en la manipulación de datos, puede llegar a ser usada tambien para la edición de los detalles asociados al maestro de datos. Eso forma parte de la idea u objetivo deseado, que es la generación y uso de prototipos. Imaginemos la rejilla general de clientes, ¿de que nos serviremos para acceder a la ficha del cliente?. La respuesta es la que imaginais: de una instancia de TRejilla, que será la que nos lanzará el formulario de edición de registro. Pero... una vez dentro de esta: ¿por que no van  a existir otros detalles? El cliente tendrá direcciones, pero tambien catalogos, tendrá tarifas, tendra un detalle de comisionistas. Otra instancia de TRejilla puede ser usada perfectamente siguiendo el mismo patrón, creando esquemas fáciles de memorizar de la estructura de cada módulo. En ese momento uno se da cuenta de que no necesita memorizarlos sino saber si ese módulo cumple con ese esquema general, lo cual facilitá el manteniento semanas o meses despues. Cada vez que construyas un modulo que se acople al prototipo deseado, menor coste de mantenimiento a medio y largo plazo.

Aunque no siempre, uno se puede ajustar, puesto que la convivencia de un modelo basado en la cache local, como es este, puede llegar a tener que convivir con la gestión de información real, capturada a través de consultas directas y puede ser problematico que ambos modelos convivan. Así que es posible que exista un pequeño porcentaje de formularios que requieran otro prototipo diferente, lo cual hasta cierto punto resulta lógico.

Tenemos que seguir avanzando. Otro paso mas. Allá vamos Ian...

Abrir el proyecto donde lo dejamos. En el IDE de Delphi hacemos "File->New->VCL Forms application - Delphi for Win32" y llamamos a ese nuevo formulario creado como "UAncestro.pas", guardandolo en la carpeta deseada. Podemos fijar el nombre del mismo como Ancestro.

Esta es sección de interface del modulo que Ian nos propone:

unit UAncestro;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, Registry, ComCtrls;

type
  IRegistroPropiedades = interface
  ['{365DAA3B-DADE-4FBD-9472-ED6F84D3B1DE}']
    procedure Leer(R: TRegIniFile; const Seccion: string);
    procedure Guardar(R: TRegIniFile; const Seccion: string);
  end;

  TAncestro = class(TForm)
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
    procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean);
    procedure FormCreate(Sender: TObject);
  private
  protected
    function Modificado: Boolean; virtual;
    function Confirmar: TModalResult; virtual;
    procedure Guardar; virtual;
    procedure Descartar; virtual;
  protected
    procedure RegistroLeer; virtual;
    procedure RegistroGuardar; virtual;
  public
    class function Ejecutar(AOwner: TComponent = nil): TModalResult;
    class function Instancia: TAncestro;
    class function Mostrar: TAncestro;
  end;

En fin... vamos a aplicar el primer recorte y le damos un tijeretazo a lo que hace referencia a la persistencia (a la interfaz IRegistroPropiedades). Tambien hemos suprimido la implementación del evento OnCreate que tampoco es imprescindible. Ahora añadimos un componente a nuestro formulario de la clase TActionList, donde se va a establecer una nueva acción que llamaremos "acFinalizar" y generamos la respuestas al evento OnExecute de la misma. Para lanzarla le he definido un Shortcut en el inspector de objetos asignando la pulsación de las teclas (Shift+Ctrl+F12). El proposito lo veremos al comentar el evento OnCloseQuery del formulario. Esto es lo que nos queda:

unit UAncestro;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, Registry, ComCtrls, ActnList;

type

  TAncestro = class(TForm)
    ActionList1: TActionList;
    acFinalizar: TAction;
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
    procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean);
    procedure acFinalizarExecute(Sender: TObject);
  private
  protected
    function Modificado: Boolean; virtual;
    function Confirmar: TModalResult; virtual;
    procedure Guardar; virtual;
    procedure Descartar; virtual;
  protected
    procedure RegistroLeer; virtual;
    procedure RegistroGuardar; virtual;
  public
    class function Ejecutar(AOwner: TComponent = nil): TModalResult;
    class function Instancia: TAncestro;
    class function Mostrar: TAncestro;
  end;

Empezamos a trabajar en la implementación del módulo donde vamos a intentar comentar los razonamientos que encierran estas funciones.

Añadimos un recurso de cadena (esto será necesario para el diálogo de la acción).

resourcestring
  SForzarCierre = 'Si sigues adelante los cambios se perderán.'#13'¿Seguir? (S/N) ';

Las tres funciones de clase definidas para TAncestro en la parte publica (Mostrar/Instancia y Ejecutar) van a ser parte de los engranajes mas importantes en la transición entre formularios. Vamos a ver la implementación y la comentamos.

class function TAncestro.Ejecutar(AOwner: TComponent): TModalResult;
begin
  if AOwner = nil then
    AOwner := Application.MainForm;
  with Create(AOwner) do
  try
    Result := ShowModal;
  finally
    Free;
  end;
end;

class function TAncestro.Instancia: TAncestro;
var
  I: Integer;
begin
  for I := Screen.FormCount - 1 downto 0 do
  begin
    TForm(Result) := Screen.Forms[I];
    if Result.ClassType = Self then Exit;
  end;
  Result := nil;
end;

class function TAncestro.Mostrar: TAncestro;
begin
  Result := Instancia;
  if Assigned(Result) then
  begin
    if Result.WindowState = wsMinimized then
      ShowWindow(Result.Handle, SW_RESTORE);
    Result.BringToFront;
  end
  else
  begin
    Result := Create(Application.MainForm);
    Result.Show;
  end;
end;

Todo empieza cuando la ventana principal llama a la función de clase Mostrar. Pero ¿Quien llama a mostrar? Lo mejor es que lo veamos con la implementación de la acción que nos permite acceder al modulo de beneficiarios. 

procedure TPrincipal.VerBeneficiariosExecute(Sender: TObject);
begin
  TBeneficiarios.Mostrar;
end;

¡Vale!  TBeneficiarios es un de las clases que va a descender de TBrowser y dado que puede ejecutar el metodo definido en su ascendente, el resultado va a ser como sigue: primero se evalua la llamada a Instancia que va a devolvernos si la ventana ya se encuentra en ejecución (fijaros como Ian recorre todos los formularios de la matriz Screen para saber si ya se encuentra activo). Y depende del valor de esta referencia (si es nil o se encuentra asigndada) decidirá entre crear o reactivar el formulario respectivamente.

El resultado final es que tenemos un mecanismo comun a todos los formularios que sean descendientes de nuestro TBrowser, que van a ser la clase que nos muestre la rejilla de datos de trabajo.

Y con respecto a la función de clase Ejecutar, nos permitirá invocar la creación de los descendientes de TDialogo, que serán las fichas o formularios en los que el usuario podrá modificar o insertar registros. La clave es entender que la llamada a Create se ejecutará en el contexto de la clase descendiente, por lo que el resultado final es la creación del formulario y el consiguiente lanzamiento modal.

Para finalizar vamos a ver la implementación del bloque de procedimientos que permiten a Ian Marteens decidir que hacer con los cambios que ha hecho el usuario. Daros cuenta como el nivel de abstracción es grande. Se establecen las lineas de que va a hacer en cada caso pero no se preocupa a este nivel de su definición. Precisamente serán las clases descendientes las que tengan la responsabilidad de dar contenido a los procedimientos virtuales como Guardar o Descartar.

Quedaría como sigue:

procedure TAncestro.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  Action := caFree;
end;

procedure TAncestro.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  case ModalResult of
    mrNone:
      if Modificado then
        case Confirmar of
          mrYes: Guardar;
          mrCancel: CanClose := False;
        else
          Descartar;
        end;
    mrOk:
      Guardar;
    mrAbort: ;
  else
    if not Modificado or (Confirmar = mrYes) then
      Descartar
    else
      CanClose := False;
  end;
end;

procedure TAncestro.acFinalizarExecute(Sender: TObject);
begin
  if MessageDlg(SForzarCierre, mtWarning, [mbOk, mbCancel], 0, mbCancel) = mrOk then begin
     ModalResult:= mrAbort;
  end;
end;

function TAncestro.Confirmar: TModalResult;
var
  Mensaje: string;
  Botones: TMsgDlgButtons;
begin
  if ModalResult = mrNone then
  begin
    Mensaje := '¿Desea guardar los cambios?';
    Botones := mbYesNoCancel;
  end
  else
  begin
    Mensaje := '¿Desea abandonar los cambios?';
    Botones := [mbYes, mbNo];
  end;
  Result := MessageDlg(Mensaje, mtConfirmation, Botones, 0);
end;

function TAncestro.Modificado: Boolean;
begin
  Result := False;
end;

procedure TAncestro.Guardar;
begin
end;

procedure TAncestro.Descartar;
begin
end;

end.

No se si estais de acuerdo conmigo, pero con cuatro lineas Marteens ha definido genialmente lo que hubieran podido ser tediosas repeticiones en cada uno de los modulos creados, de no haber utilizado este tipo de prototipos. Creo que cualquier programador disfruta cuando encuentra en su camino código que le hace pensar como hacer mejor las cosas y este módulo es un buen ejemplo de ello, sobretodo por su sencillez.

Nuestro usuario hizo doble click sobre la rejilla, o lanzó la ejecución de las acciones Editar o Insertar de menús o botones, y tras modificar los valores en el formulario, llega el momento inevitable en el que tiene que confirmar o descartar cambios.  ¿Hacia donde pues deberiamos mirar para entender está pasando en ese bloque de código? Parece que la clave es evaluar la respuesta del usuario (saber si ha aceptado los cambios y bien los ha rechazado) y en función de esta respuesta actuar.

Eso sí, ese actuar, va condicionandose en funcion tambien de que existan modificaciones o no (nos lo diría la llamada a Modificado) ya que no es lo mismo que el usuario haya pulsado aceptar o descartar cambios. Tambien se previene que el usuario accidentalmente pueda perder los cambios hechos cancelando de forma fortuita, momento en el que un dialogo modal debería rescatarlo y darle la posibilidad de salvarlos adecuadamente.

Con respecto a la acción Finalizar, que no figura inicialmente en el framework, se corresponde con una "necesidad" descubierta durante el desarrollo real. Vereis, siempre partimos de situaciones felices en las que prevenimos los problemas que mas o menos vislumbramos en la etapa de analisis. En algunas ocasiones, si se producía una excepción durante el proceso de cierre de la ventana modal, era posible que esta no pudiera ser cerrada, ya que el usuario ni podía confirmar los cambios ni descartarlos. En una situación donde no existía forma de escapar, suponía un pequeño truco útil para que el usuario pudiera escapar del nudo, sabiendo que serían descartados los cambios hechos en la edición de la ficha, como mal menor. Por esa razón se reserva el tratamiento de la respuesta Abort que escapa y permite cerrar el formulario y descartar los cambios. Pero esto habría que verlo desde el enfoque de una solución de urgencia  y no como un tratamiento a la excepción. De hecho, en una aplicación real podría existir un mecanismo de comunicación con el departamento de desarrollo para recibir esta incidencia  (via mail, via log) y tratarla adecuadamente en una versión posterior.

Hasta aquí nos ha llevado el comentario de la clase TAncestro. El siguiente peldaño nos llevaría a estudiar las dos clases que descienden directamente de ésta, en la relación de jerarquía: TBrowser y TDialogo. Además, va a ser una buena excusa para ver de cerca otro detalle muy interesante, que son las interfaces. Seguimos en la primera semana del próximo mes.

Los que podais estar interesados en el curso de Marteens sabeis que podeis encontrar información pulsando en:

http://www.marteens.com/

  Siempre repito (creo que debo comentarlo al final de cada entrada de la serie) que estas entradas son meramente comentarios de un programador que ha seguido en su trabajo uno de los frameworks de los cursos y que está compartiendo esa experiencia con la comunidad. A mi, personalmente, me ha parecido fantástico y lo tengo en una valoración muy alta. No existe la intención de recrear todo el framework sino simplemente comentar los puntos que me parecen claves o interesantes del mismo, aunque logicamente, para poder verlos, le pedí permiso previamente a Ian, que no puso objeción, tal y como comenté en la primera de las entradas.

 Hago y recalco este comentario para que no haya quien crea que Marteens participa de algun modo conociendo el contenido de estas entradas o dando el visto bueno a lo que voy escribiendo. En todo caso, yo como muestra de agradecimiento, dado que estas páginas no tienen caracter lucrativo sino todo lo contrario y es la unica forma que tengo de agradecercelo, estoy incluyendo al final un enlace a los cursos, con independencia de que piense que es un dinero bien gastado y se lo pueda recomendar abiertamente a los programadores que se inician en Delphi. Pero tampoco es algo que me haya pedido el, porque entre otras cosas tampoco lo necesita.

Hay muchos libros y documentación en los que se puede conocer la sintaxis del lenguaje o el uso de tal o cual componente o de tal o cual estructura... pero prácticamente ninguno donde puedas ver de cerca el desarrollo de gestión de datos con el detalle con el que Marteens los aborda.

Nada mas. Espero que pueda ayudar a alguien todos estos comentarios.