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

[Bauhaus1975]

Hola a todos, con este post pretendo aprender y dejar algunas explicaciones resultas de aquellos de vosotros que tenéis más experiencia o más creatividad.
Se trata de que deis vuestra opinión de cómo organizar formularios, métodos de funcionamientos (interfaces en definitiva) y podamos aprender o dejar plasmadas aquí algunas recomendaciones a la hora de diseñar funcionamientos más o menos habituales.

Primer caso: Cómo organizar el funcionamiento de un módulo o parte de programa que maneja entidades con muchos elementos, y necesitamos administrar con las funciones habituales de crear, editar, eliminar, buscar… El ejemplo más claro puede ser la parte de manejo de clientes de un programa, en el que puede haber cientos de elementos y necesitamos acceder de manera rápida y manejar fichas con numerosos campos.
¿Cómo organizarían el / los formulario/s, su funcionamiento etc?
¿Qué componentes usarían para facilitar las cosas en el caso que he descrito?

Espero que este tipo de debates aporten conocimiento y sean de provecho.
Gracias a todos.

[pvizcay]

En dicho caso yo tengo dos entidades básicas:

> una lista, donde se ven los elementos a trabajar en una grilla con sus datos más importantes (en tu caso los clientes) y donde tenes los comandos Agregar, Editar y Eliminar

> un editor donde ves el "detalle" de la entidad (el cual se abre al selecionar agregar y editar desde la lista) donde estan todos los campos del cliente (en el editor solo podes ver uno)

salu2

[Bauhaus1975]

Hola, y gracias por ser el primero en dar tu opinión. Ciertamente, como dices es cómo me parece más cómodo. Así tendríamos DOS Formularios que se abrirían modalmente (Listados y Ficha):

1. Formulario para listar los elementos (clientes) en un tipo de Grid, pienso que en este form debe incorporarse la funcionalidad para buscar por combinación de criterios (p.e. apellidos, DNI...), y/o búsquedas directas (p.e. últimos dados de alta etc.) También desde aquí debería poder enlazarse con la funcionalidad de nuevo, edición (al pulsar el elemento seleccionado), eliminar.

2. Formulario Ficha. Aquí estarían todos los datos o campos del cliente. Para dar de alta nuevo o modificar, según de la acción de la que vengamos. Si hay muchos datos se podría usar un PageControl para organizarlo mejor.

3. Podría existir un tercer formulario para búsquedas rápidas de algunos criterios, con idea de añadir esta funcionalidad cuando en otras partes del programa hay que añadir un cliente, así se podría seleccionar de este formulario. Si no hubiera muchos elementos, una lista con todo podría servir.

Ahora, con la cantidad de librerías de componentes que hay.. no sé si alguien tiene una idea mejor de organización.

[[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