Comunidad Gambas-es

A la hora de manejar tablas, veo continuamente en el código subido a este foro tediosas ristras de nombres de campo una y otra vez. Cosas como ésta:


Donde el programador ha cambiado el nombre de los campos, dándole sentido al código, lo cual está muy bien. Pero ¿y si la tabla tiene 30 campos, o 100? Qué pesadez ¿no? y a la hora de grabar, a repetirlo todo al revés:

etc., etc. hasta los 30.. o 100 campos

Personalmente odio ese tipo de código. Es aburrido de teclear, fácil de cometer errores, largo de leer y complicado de modificar. Por tanto hace tiempo que diseñé unas funcioncitas que me hacen el trabajo sucio:
Con ellas el ejemplo anterior quedaría así:

¿No es mucho más simple y claro?
En el momento de grabar un registro nuevo, sólo tenéis que añadir la linea

Para grabar los datos de la pantalla:

Para limpiar los campos después de grabar o antes de mostrar campos nuevos:


Para que os funcione tan sólo tenéis que hacer una cosa muy sencilla:
Que los campos se llamen igual que los campos de la base de datos. Si el campo es "apellidos" en la tabla, el TextBox ha de llamarse "apellidos".

¿Y qué pasa con los ComboBox? "Tengo varios comboBox que me muestran los datos de otras tablas con las que se relaciona ésta"... pensaréis
En ese caso basta con añadir en tiempo de diseño la siguiente cadena en la propiedad Tag del combobox:
tabla_relacionada|campo_a_grabar|campo_a_mostrar1|campo_a_mostrar2|campo_a_mostrar3...etc
Ejemplo:
Siguiendo el ejemplo de arriba, estamos manejando la tabla Asistencias que tiene una referencia a los asesores.
Creamos un ComboBox que se llama "asesorid" (el mismo nombre que el campo de la tabla, recordad) y en el tag ponemos la siguiente cadena:
asesores|id|apellidos|nombre

Y ya está, nuestro combo se llenará automáticamente con el contenido de la tabla de asesores y grabará en la tabla el id del asesor cuando llamemos a la función grabaregistro.

Sólo un detalle más: Si tenéis algún campo que queréis mostrar, pero no grabar (como pueden ser los autonuméricos o los timestamp), basta con poner en tiempo de diseño un FALSE en el Tag del campo.


Esta solución es la que utilizo siempre. El código gana en limpieza, velocidad de escritura y en facilidad de lectura.
He subido una demostración de actualización de una tabla que tiene un campo vinculado con otra. No tenéis ni que entender el código que os adjunto aquí. Veréis que es muy sencillo de manejar.

Lo podéis descargar de Aquí:http://desconcertado.es/archivos/Ejemplo_formularios.zip

Como el código que subí es una versión modificada del que uso de verdad (no uso connection, sino una clase derivada, y había imbricado en estas funciones el código de seguimiento de los usuarios, etc.), había dejado por ahí algunas líneas de código fósil... Lo he corregido. Ahora el código es más sencillo.

Fijaos que en todo el formulario no se menciona ningún nombre de campo (salvo el que hace de clave primaria), lo que quiere decir que el 90 % del código del formulario es reutilizable tal como está para casi cualquier tabla de casi cualquier base de datos. Sólo habría que cambiar el valor de la variable privada "tabla" y dibujar los controles de la nueva tabla... más o menos.

Ya me contáis.

Excelente catedra, gracias.

Ya hace mucho que no pongo nombres de campos en la actualización, creación, etc. de mantenimientos normales. Si os sirve como ejemplo, me he diseñado una clase que instancio desde el formulario que hace el mantenimiento y que tiene en su propiedad tag el nombre de la tabla y el campo índice PK. Este formulario tiene textbox, combos, spinbox, checkbox, textarea, y/o valuebox, los cuales en su tag tienen el nombre del campo al que hacen referencia, el cual se actualiza según ejecute el método new, edit, etc. El Combo tiene otra información por ser un caso especial. Los combos los rellena automaticamente cuando carga la clase. También gestiona labels para mostrar información que no quiero que se modifique (solo ver). Esta clase tiene un método bookmark que me permite situar el puntero de la tabla donde quiero pasándole el num. de registro como parámetro. Tiene 2 prop. EditMode (para cuando el registro esta en edición) y AddMode (cuando esta añadiendo). Para controlar ciertas circunstancias especiales, genera eventos ShowData, cada vez que muestra el registro, BeforeSave antes de grabar, AfterSave despues de grabar, BeforeUpdate y AfterUpdate, BeforeDelete, AfterDelete y más, si te lo haces tu... tantos como quieras según tus necesidades. También por unificar crea una barra de navegación standard con los botones primer registro, anterior, siguiente, ultimo, añadir, modificar, borrar y un label con el registro x del total y. que se corresponde con el menu del formulario (creado también en la clase cData). Estos botones y op. de menú se activan y desactivan automáticamente.
Como es para mí, está poco protegida y dejo muchas variables como públicas incluido el result con la carga de los datos, pero desde el formulario principal con tantos eventos y tan abierto hago lo que quiero.

Si hay alguien interesado la subo para que os sirva de ejemplo. Tened en cuenta que como ha sido fruto de ir creciendo con las necesidades no esta demasiado limpia, pero tiene cosas interesantes como por ejemplo una función recursiva para repasar todos los controles que cambian la prop. readOnly después de grabar, al editar, etc.

Un saludo

Pues a mí me interesa. Pásala, que siempre es una maravilla ver cómo dos cerebros distintos solucionan el mismo problema... es más, seguro que más de uno tiene hecho algo para ahorrarse los nombrecitos dichosos. Estaría guay que se animase y subiesen las distintas soluciones.

Suerte

Como la mejor forma de verlo es en un programa, he hecho uno con 2 mantenimientos y un formulario de busqueda para que se vea como usa el método bookmark. La revisais y si no entendeis algo, ya sabes, a preguntar. Me gustaría que si se os ocurre añadir algo y es interesante, me lo hagais saber.

No obstante la clase esta hecha para que simplemente la importeis a vuestro proyecto e instanciándola como vereís en el formulario de esta aplicación, a funcionar. Las instrucciones de como manejar los tag en los controles enlazados están comentadas al principio de la clase cData.class.

Hecho con gambas 2.21 sobre Ubuntu 10.04.

Importante para que el programita funcione, sacar el fichero sqlite3 (mybooks.db) del tar y si quieres por no descomprimir, he puesto también el ejecutable

Un saludo,

EDITO: He olvidado decir que quien use la clase cData, debe poner el Arrangement del formulario en vertical para que la barra de navegación se añada correctamente al final del form. Yo como vereís en el ejemplo lo soluciono todo con containers para alojar los controles.

A mi la verdad shordi me parece un error de planteamiento. Creo que tu sistema funciona pero no es funcional. Tu usas valores como el TAG para pasar valores e indicar la acción a realizar en base de datos. Al hacerlo estas mezclando CAPAS y estás usando la capa de usuario para controlar la CAPA de base de datos.

Tu problema es que el cambio de un solo formulario o control en tu aplicación requiere el conocimiento de la base de datos. Ambas lógicas están unidas y puede ocurrir que el cambio de un formulario lleve a que tu base de datos no grabe o no grabe bien los datos. Es lo que pasa cuando se mezclan capas distintas. Tú no lo ves porque solo tú tocas ambas cosas pero si hubiera varias personas lo verías y te encontrarías explicándole a un tio que se encarga de gestionar los formularios cosas de base de datos que no tiene porque saber.

Te diré como lo hago yo.

Pongamos una gestión de altas/bajas/modificaciones de clientes.

Yo creo un formulario para todo eso. En ese formulario me encargo de saber la operación que se quiere realizar. En el form_load si es un alta el formulario debe mostrarse vacío. Si no es un alta entonces debe mostrarse el formulario lleno. Al final hay un botón ACEPTAR y ese aceptar lleva a cabo la acción de dar la ALTA, BAJA o MODIFICACION.

El formulario solo hace eso y nada mas que eso.

A la vez que el formulario creo una clase llamada nombreformularioCLS. En esta clase hay típicamente cuatro funciones públicas: VALIDAR, INSERTAR, MODIFICAR y BORRAR.

En el botón aceptar de antes lo único que hago es llamar a la función VALIDAR para saber si los datos actuales en el formulario son válidos para realizar la operación. Si lo son se llama a la función correspondiente (insertar, modificar o borrar) con los valores del formulario correspondientes como parámetros.

VALIDAR
Se comprueba que estén debidamente completados los campos requeridos. Esta función por tanto recibe como parámetro la operación a realizar y los valores de los campos que debe comprobar. Devuelve true o false.

MODIFICACIONES
Esta función llama a la función privada GrabarDatos con un parámetro opcional que es la clave del registro a modificar y la lista de valores a grabar.

INSERTAR
Esta función llama a la función privada GrabarDatos SIN el parámetro opcional y le pasa los datos a grabar.

BORRAR
Esta función borra el registro indicado en la clave que recibe como parámetro.

GrabarDatos
Esta función es la que realmente realiza la operación. Si existe el parámetro opcional entonces busca el registro adecuado. Si el parámetro opcional no existe entonces hace un addnew.. Luego pasa los parámetros que ha recibido a sus campos respectivos y graba. Devuelve la clave de registro que ha escrito o nada si hubo error.

Como ves yo tengo un formulario para gestionar la pantalla y una clase para gestionar los cálculos y acceso a base de datos. El modificar uno no requiere modificar el otro y esas ristras de campos que dices solo se escriben una vez y allí se controla si hubo error. Para llegar a eso los datos han sido previamente validados

De manera que el botón aceptar del formulario tiene un código como este

Ese es todo el código de base de datos que encontrarás en mi formulario.

No pongo el código de esas funciones (que son cuatro líneas) por no hacerlo mas pesado pero si alguien cree que lo verá mas claro se lo pongo en un momento. Son cuatro lineas cada uno pero me he dado cuenta que cuanto pongo código a menudo la gente luego no lo lee.

AHH justo ahora veo que ahtonio ha puesto algo. Hemos coincidido en el tiempo je je. A ver si también coincidimos en el concepto.

Casi me siento un poco ridículo Soplo. Tu con 4 líneas parece que has solucionado tu operativa y yo te mando una clase que controla el modo de operación y forma con 915 líneas. Supongo que la clase que he escrito obliga a un modo de funcionamiento, un control de campos, etc. que espero haya merecido la pena. Si tienes algún comentario, será bien recibido.

Un abrazo

Hay varias clases que ver en lo que has puesto. Luego lo miro con cuidado pero te pongo las funciones básicas de las que he hablado.

Primero dejar en la variable Accion la operación que se quiere realizar


Ahora la función que valida si la operación a realizar tiene los datos apropiados o no. Para ilustrar el caso pongamos que la acción a realizar e 1 ó 2 (altas o modificaciones) y que queremos comprobar que el param1 contiene algo y que param2 y param3 son fechas. Param2 debe ser una fecha menor que param3
'La función de validar el alta. Como dije Param1 tiene que contener algo, Param2 y Param3 deben ser fechas y
Param2 debe ser una fecha anterior a Param3
Con eso ya puedo validar.

Ahora la función de Altas. Devuelve el key del registro dado de altas


Ahora la función de modificar. Parecida a la de altas pero incluye además la clave del registro a modificar


Ahora el código de grabar datos


Me queda la función de borrar. Devuelve la cantidad de registros borrados. Debería ser 1 si fue bin o 0 si fue mal


Como ves lo de tres o cuatro líneas cada función pudo ser un exceso, pero si quito comentarios ninguna de ellas pasa de las diez líneas ja ja ja pero no te sientas ridículo. Sospecho que lo tuyo está mejor solo que tengo que leerlo

jeje Soplo, lo que decía, los cerebros distintos producen soluciones distintas.
Tú separas en capas, lo cual está muy bien, por supuesto, y posiblemente sea más ortodoxo que lo que yo hago. Pero adolece de lo que yo intento evitar: Tener que programar los accesos, juntos o separados, a cada tabla y cada formulario. Yo siempre he buscado, y en ese sentido va mi solución, el trabajar sólo una vez para todas.
Con mi sistema, a la hora de funcionar, no es necesario saber nada más que los nombres y tipos de los campos y las relaciones entre las tablas y, a veces, por lo que más abajo explico, ni eso. No creo que a nadie se le pueda encargar un manejo de datos sin conocer mínimamente eso.
De todas formas, tengo hecho un paso más (sólo que no lo he subido por no mezclar churras y merinas), que es un formulario auto-creable, que permite actualizar cualquier tabla, respetando la integridad referencial y generando automáticamente los combos con los campos que necesites. Algo parecido a lo que hacen programas como phpmyadmin, por ejemplo, a la hora de editar una tabla. Con éste formulario, sólo te tienes que preocupar por programar las validaciones de los campos (que no esté vacío, etc), lo cual se puede hacer en un módulo separado para cada tabla y olvidarte por completo de los formularios, que la aplicación los genera ella solita.
Lo cuento porque es un paso más en la dirección que yo voy, a saber: que cuanto menos se codifique para cada proyecto concreto, mejor.
La solución de ahtonio no he tenido tiempo de verla, pero en cuanto la vea os cuento qué me parece.

Saludos.