Usabilidad. Entidades numerosas ¿cómo harían?

[[Lepe]]

Aunque Microsoft desaconseja el uso de interfaz MDI, y salvando los errores conocidos, prefiero usar esta interfaz por tener todo recojido. Las ventanas modales, sólo las uso cuando no se puede continuar la aplicación porque necesita datos vitales.

1.Formulario para listar los elementos (clientes): No sé a que le llamas "enlazar con la opción de Nuevo/modificar/eliminar". Yo lo que hago es llamar a la ventana de cliente especificando el IDCliente. La ventana de "listar" no puede modificar ni eliminar, sólo llama a la ventana de clientes al hacer doble clic. (elimino duplicidad de código, y posibles efectos colaterales).

2. Formulario Ficha. (nada que comentar, concuerdo totalmente).

3. Búsquedas rápidas: Yo actualmente uso un Frame, contiene un grid con un Toolbar. Me permite explorar / localizar / imprimir cualquier elemento (cliente, factura, albaran, empresa) con sólo especificar un parámetro.

Para el tercer punto, uso una metodología estricta en mis tablas:
- Nombre de tabla: cliente, factura
- clave primaria: IDcliente, IDfactura

Este frame recibe el parámetro "nombre de tabla", si le paso
"cliente", crea la sql de búsqueda "SELECT * FROM CLIENTE WHERE CLIENTE LIKE '%' + edtBusqueda.text+ '%' + 'ORDER BY IDCLIENTE".

Al hacer doble clic en el grid, se abre su ventana propia (factura, cliente, etc), localizando el elemento.

Nota: En realidad no uso parámetros de tipo string, tengo declarado algo así:

Código Delphi [-]
unit global;

interface

type TVentana = (vCliente, vFactura, vAlbaran);

var VentanaDesc = array [TVentana] of string = ('cliente', 'factura', 'albaran');

function AbreVentana(tipo:TVentana; const ID:integer = 0):TBaseForm;

Aquí otro truco más, Tengo un Formulario Base del que heredan todas las ventanas con la propiedad ID:integer.

AbreVentana crea el tipo de ventana TFrmClientes y asigna el ID si es distinto de cero, después muestra la ventana en pantalla.

Saludos

[Bauhaus1975]

Hola

Empezado por Lepe

1.Formulario para listar los elementos (clientes): No sé a que le llamas "enlazar con la opción de Nuevo/modificar/eliminar".

Pues que desde donde se listan los elementos, encontramos botones o 'maneras' para desencadenar las acciones de Nuevo, modificar o eliminar. En los dos últimos casos previa selección del elemento (cliente), creo que igual que tú explicabas. Efectivamente, creo que lo mejor es que desde donde se listan los elementos no se puedan modificar.

Tu aportación sobre como organizar el código para búsquedas es interesante, aunque yo intento no tener funciones 'sueltas', sólo métodos de clase.

Para búsquedas rápidas propondría tener un formulario (clase heredada de TForm). En tiempo de ejecución añadiríamos un par de componentes para recibir parámetros (segun la entidad de la q se trate) y poder buscar con ellos. Y que éste formulario fuera capaz de devolver el (Id,nombre,..) al formulario que espera el dato. Haria falta para ello tener definido para cada entidad (cliente, factura etc) que parametros son necesarios para búsquedas rápidas.

[[Lepe]]

Empezado por Bauhaus1975

yo intento no tener funciones 'sueltas', sólo métodos de clase.

Entonces creas una clase llamada TVentanaAdmin con el método AbrirVentana (no tomes al pié de la letra lo que digo, ya que para que se entienda, omito algunos detalles de implementación ).

Empezado por Bauhaus1975

Haria falta para ello tener definido para cada entidad (cliente, factura etc) que parametros son necesarios para búsquedas rápidas.

Si sigues la metodología que digo, siempre buscarás por el campo principal de la tabla.

La ventana de búsqueda, puede tener un método llamado "LookUp" que hace un fieldbyname sobre el query de búsqueda, devolviendo un Variant por ejemplo. De esta forma la ventana de búsqueda puede devolver en tiempo de ejecución cualquier campo del dataset.

Otra forma de afrontar las búsquedas, es usando una tabla de configuración, por ejemplo la tabla config tiene dos campos de tipo string:

codigo                     Valor
-------------------------------------------------------------------------
ClientesSQL                select * from Vistaclientes where %s
ClientesFieldsSearch       Nombre,Dni,Domicilio,Telefono
FacturaSQL                 select * from Vistafacturas where %s order by numFactura
FacturaFieldsSearch        numFactura,Cliente,fecha

De esta forma una ventana general de búsqueda puede cargar dinámicamente los campos y SQLs, formateándolo sin importar en qué tabla está buscando. Como ves, uso una Vista (view si el motor lo soporta), donde se muestra el nombre del cliente que obviamente la tabla Facturas no lo tendrá (solo guardará el IDCliente).

"FieldsSearch" puede cargarse en el commaText de un ComboBox, por ejemplo, para que el usuario decida el campo de búsqueda y pueda añadir varios criterios a la vez.

Saludos

[Bauhaus1975]

Creo que te entiendo...
También las propiedades de búsqueda que comentas en vez de almacenarlas en una tabla podrían ser una propiedad de la clase TVentanaAdmin, ¿cierto?
Incluso podría ser una propiedad 'paramsBusqueda' que fuera una lista de TField, de esta manera al llamar a la ventana de búsqueda rápida con pasar la lista de parámetros y la tabla podría tanto añadir los componentes en tiempo de ejecución para realizar la búsqueda, como hacer la query una vez invocada la búsqueda. ¿y para retornar el valor seleccionado?

Otra cosa, antes mencionaste que no aconsejabas el uso de ShowModal, puedes dar tu consejo de como organizar / visualizar estos formularios que estamos comentado,
Gracias por tu aportación.

[[Lepe]]

Empezado por Bauhaus1975

Creo que te entiendo...
También las propiedades de búsqueda que comentas en vez de almacenarlas en una tabla podrían ser una propiedad de la clase TVentanaAdmin, ¿cierto?

Si lo guardas en TVentanaAdmin, esa configuración tendrás que guardarlo en algún sitio ¿un archivo ini?, ¿codificadas en delphi? Al tenerlo en una tabla de la base de datos, puedes usar IBExpert para añadir campos de búsqueda o eliminar alguno que se te haya pasado. También puedes modificar (con ciertas limitaciones) las sqls de búsqueda.

Empezado por Bauhaus1975

Incluso podría ser una propiedad 'paramsBusqueda' que fuera una lista de TField,

Eso te obliga de nuevo a tener los campos persistentes en delphi, es decir, no puedes utilizar la misma ventana para facturas y clientes, porque obviamente cada uno tendrá campos distintos.

La ventana de búsqueda rápida tendrá un TQuery, pero se configura todo en tiempo de ejecución, por eso tienes la libertad de usarlo con varias tablas sin problemas. Me explico mejor:

Tienes un Grid que va ligado a un TQuery, el TQuery no tiene nada en la propiedad SQL en tiempo de diseño. En ejecución, se le asigna la propiedad SQL a:

Código SQL [-]
select * from Clientes

Justo antes de abrirse el TQuery es cuando se rellena internamente con todos los campos que tenga la tabla clientes. Si en lugar de usar "clientes" usas "facturas" obviamente ahora el mismo TQuery tiene los campos de la tabla factura. Todo se hace en tiempo de ejecución.

Ahora puedes hacer:

Código Delphi [-]

function TFrame1.ObtenerValorDeCampo(NombreCampo:string):string;
begin 
  if query1.Active then
    Result := query1.Fieldbyname(nombreCampo).AsString;
end;

Que podrás llamar con result := ObtenerValorDeCampo('Cliente')

Empezado por Bauhaus1975

Otra cosa, antes mencionaste que no aconsejabas el uso de ShowModal,

Este tema da para un hilo completo .

Personalmente, para programas de facturación, me gusta una interfaz MDI (Multiple Document Interface), por ello todas las ventanas de clientes, facturas, etc, se abren dentro de la ventana principal, que tiene un menú y un toolbar. Como el usuario puede abrir varias ventanas al mismo tiempo, que él mismo se organice . Es más o menos este ejemplo (en el hilo completo puedes ver muchos ejemplos de los foristas).

La ventana de búsqueda rápida, sí es una buena candidata para ser modal, ya que necesita que el usuario de doble clic en un resultado para que la ventana de clientes muestre todos los datos, dicho de otra forma: Una ventana necesita de información proporcionada por otra para continuar, siempre que se cumple esa regla, usaría una ventana modal.

Por contra, la ventana de búsqueda normal (la que permite búsquedas avanzadas) no la hago modal, puede necesitar abrir la ventana de facturas para ver una fecha (por ejemplo).

No he diseñado aplicaciones SDI (sólo pequeñas utilidades con 2 o 3 ventanas a lo sumo) que son fáciles de administrar.

Saludos

[Bauhaus1975]

Mentalmente me había imaginado una clase padre, abstracta que defina propiedades comunes y métodos comunes. Luego cada tipo de formulario particular (clase que herede) podría contener su propia información de configuracion, como parámetros para busqueda rápida, tabla en la que están los datos etc. Aunque también se pueden tener en base de datos como dices.

Sobre MIDI / modal, yo tengo cierta tendencia al uso de ventanas modales porque tengo poca experiencia con Delphi, además si se pueden tener varias ventanas abiertas se pueden realizar modificaciones que impliquen refrescar datos o aplicar cambios en otras ventanas. Esto me complica bastante el funcionamiento.

Echaremos un vistazo al hilo que aportas. Gracias.

Saludos.

[[Lepe]]

Bueno, realmente no sé lo que necesitas y cuan complejo son las búsquedas a realizar. sea como fuere, solo te digo: KISS.

Keep It Simple Stupid . Es una filosofía de diseño bastante antigua; aunque la tarea a realizar sea compleja, ¡hazlo simple!.

Para lo de refrescar datos, piensa en un método genérico de tu Clase Base "RefrescarDatos" o "ReloadConfig", las clases hijas se encargan de cerrar los datasets y abrirlos de nuevo o de cargar de nuevo la configuración. Al estar en la clase padre, puedes hacer algo como:

Código Delphi [-]
for i:= 0 to screen.count -1 do
  if Screen.Forms[i] is TClaseBase then
   begin
    TClaseBase(Forms[i]).RefrescarDatos;
    TClaseBase(Forms[i]).ReloadConfig;
   end;

Saludos