Ir al contenido


Foto

Metodo de actualizacion de controles visuales


  • Por favor identifícate para responder
4 respuestas en este tema

#1 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 28 septiembre 2017 - 10:21

Quería preguntarles si alguien leyó o hizo alguna vez algo similar.

 

Se me ocurre hace un procedimiento que actualize todos los controles visuales que muestran algun dato. Por ej: en un form de una factura, si agregamos o quitamos un producto, se debe actualizar los totales, ya se que el cleintdataset tiene la opcion agreggates por ejemplo.

 

Pero tengo un campo donde se ingresa el efectivo entregado por el cliente, y se autocompleta el vuelto en otro edit. si se agregaria otro producto aumenta el total y disminuye el vuelto. Osea me refiero a todos los cambios que puedan ocurrir.

 

Osea la idea seria llamar a este procedimiento en cada proceso que hace una modificacion. Y lo que haria seria resetear, volver a escribir todos los valores. De esta manera se centraliza esta tarea. Hasta podriamos trabajar con stringgrid y no dbgrid.


  • 0

#2 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 28 septiembre 2017 - 12:07

Quería preguntarles si alguien leyó o hizo alguna vez algo similar.

 

Se me ocurre hace un procedimiento que actualize todos los controles visuales que muestran algun dato. Por ej: en un form de una factura, si agregamos o quitamos un producto, se debe actualizar los totales, ya se que el cleintdataset tiene la opcion agreggates por ejemplo.

 

Pero tengo un campo donde se ingresa el efectivo entregado por el cliente, y se autocompleta el vuelto en otro edit. si se agregaria otro producto aumenta el total y disminuye el vuelto. Osea me refiero a todos los cambios que puedan ocurrir.

 

Osea la idea seria llamar a este procedimiento en cada proceso que hace una modificacion. Y lo que haria seria resetear, volver a escribir todos los valores. De esta manera se centraliza esta tarea. Hasta podriamos trabajar con stringgrid y no dbgrid.

 

Eso que comentas es de lo más habitual, y necesario. Es inevitable la existencia de un hipotético método que se llame ActualizarFormFactura() y se encargue de hacer el trabajo.

La implementación real dependerá de tu diseño y tu capacidad creativa.

 

Si lo vemos desde lo más purista Orientado a Objetos, un enfoque a utilizar sería el patrón Observador. Ya se ha tratado en ocasiones este concepto. Es más hay código funcional de mi parte en el foro.

En pocas y resumidas líneas el patrón Observador plantea que existe dos tipos de clases: la Observable (llamada mayormente Sujeto) y la Observadora. La 1ra es la que va a estar en cambios y les notificará a todas las instancias de observadores que estén "registradas" en ser notificadas de algún cambio.

La idea es usar el principio "No me llames. Yo te avisaré cuando sea necesario". Generalmente uno está acostumbrado a verlo al revés. Si un objeto desea algo, se lo pide al otro.

Pero en ocasiones (sobre todo si van a ser muchos los interesados en interactuar con el objeto dependiente) el concepto es aconsejable invertirlo y hacer que sea el objeto sujeto a cambios quien avise "Hey, he cambiado X propiedad. ¿Hay alguien interesado en saber el valor?".

 

Tu clase observable puede ser TFactura, y como observadores podríamos citar el Form que está trabajando con la Factura, el form de reporte de facturas, etc.

 

En Delphi ya existe una implementación inspirada parcialmente en este concepto. Un ejemplo son los componentes Data-ware. Internamente los componentes se apoyan en unos objetos "links" que vinculan el TDataSource con los diferentes controles DB. El DataSource que actúa de intermediario, notifica a los controles de los cambios reales que se han efectuado en el TDataSet.

Pero... también hay situaciones en donde esta magia que nos ofrece Delphi se nos puede ir de la manos si uno no aplica un correcto diseño y control... Y ahí es cuando uno se debate la posibilidad de no usar Data-ware (recomiendo que te tomes el tiempo para leer ese enlace) y hacer el "trabajo duro". Ahí es cuando ya si se enfoca a aplicar el patrón Observador y hacer un diseño por lo general más purista OO y llegar a plantearse un diseño asistido por Capas.

Agustin Ortu y yo somos dos ejemplos de los que evitamos el uso de Data-ware.

 

Ahora bien ¿Merece llegarse a usar el patrón? No necesariamente, tu deberás evaluar que tanto pros como contras tendrás si lo aplicas... Ponte a pensar en cuantas clases sujetos y observadores tendrás, y/o si será util hacerlo pasar por una fachada como intermediario.

Dependiendo del "ruido" que te haga podrías tomar una decisión...

 

En ocasiones quizá no sea necesario malgastarse en usar Observer y directamente usar lo clásico:

1. Realizar la operación ABM en cuestión en la DB

2. Invocar los SELECTs que sean necesarios

3. Refrescar el contenido del form con lo obtenido de la consulta

 

Esto se podrá hacer por demanda... o hasta incluso hacer que sea automático cada x cantidad de segundos.

Insisto: que todo dependerá de tu creatividad y tu diseño. Pero de que se puede hacer seguro.

 

Saludos,


  • 2

#3 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 28 septiembre 2017 - 12:43

Poco para agregar a lo que ya dijo Marcelo. Simplemente decirte que creo que vas bien encaminado en pensar en que todo ese procesamiento debe estar centralizado en un solo lugar, en un solo metodo que hace el trabajo y actualize todos los componentes visuales. 

 

La decision de no usar data-aware te permite ir prototipando con datos falsos que mantenes en memoria e ir probando la aplicacion; incluso podrias plantear test de unidad automaticos y evitarte las pruebas manuales (obviamente las pruebas de experiencia de usuario las vas a tener que seguir haciendo a mano)


  • 1

#4 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 28 septiembre 2017 - 01:11

Gracias a los dos. Poco a poco voy tomando la "logica de programacion". Todo lo que programa uno, uno lo conoce y puede manejar mejor.

Enviado desde mi SM-G530M mediante Tapatalk
  • 0

#5 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 28 septiembre 2017 - 01:37

No está demás señalar que si se usa Firebird, tenemos otro extra que vale la pena usar en combinación: eventos.

 

Gracias a los eventos en Firebird podemos enviar mensajes desde el motor de base de datos a nuestra aplicación. Y en base a esto actuar en consecuencia. Puede ser útil justamente para esos procesos de "autorefrescar".

 

Saludos,


  • 0




IP.Board spam blocked by CleanTalk.