| Autor |
Mensaje |
dpinelo
Miembro |
# Publicado: 6 Mar 2009 13:09
Hola a todos,
He realizado algunas modificaciones en AbanQ a partir del código fuente OpenSource liberado por InfoSial, que puede que sean interesantes. Las tenéis en mi blog
http://www.davidpinelo.com
Las modificaciones son:
* He eliminado la paleta que incluía InfoSial y a que a mí personalmente, no me gustaba estéticamente
* Los formularios de edición, y de búsqueda se abren centrados en el escritorio. (Me ocurría que algunos se abrían en lugares incómodos).
* He agregado la propiedad qryVisualizacion a los componentes FLTableDB que se incluyen en QtDesigner. Esto permite, mostrar en este tipo de componentes el resultado de una query SQL en lugar de una tabla. Esto es útil, si queremos ver el valor de columnas (o campos) de otras tablas relacionadas y que no se incluyen de manera duplicada en la tabla que editamos (política general de los módulos de AbanQ).
Esta última modificación, creo es la más importante, ya que me evita el problema que ya planteé en algunos posts anteriores: El tener que duplicar información a lo largo del modelo de datos. Ya no es necesario guardar en la tabla albaranesprov (por ejemplo) el nombre del proveedor ni su CIF, puesto que en el fichero master podemos mostrar una query que haga un join de las tablas albaranesprov y proveedores tomando datos de éste último (ojo, sólo para visualización), y trabajar a la vez con los registros de albaranesprov.
En mi blog están los fuentes modificados, así como una breve explicación de qué he hecho y cómo.
Saludos
|
falbujer
Miembro |
# Publicado: 6 Mar 2009 20:18
Hola.
muy interesante, vamos a estudiarlo y tal vez podamos meter alguna de estas mejoras en la próxima revisión de mantenimiento que liberemos.
Gracias y un saludo
|
falbujer
Miembro |
# Publicado: 6 Mar 2009 20:56
Una pregunta, aún no lo he mirado así que puede que la respuesta sea obvia, pero ¿ en qué se diferencia la implementación que has hecho para manejar consultas en los FLTableDB, de la que ya tiene AbanQ utilizando la etiqueta <query></query> en los metadatos ?
Saludos.
|
dpinelo
Miembro |
# Publicado: 7 Mar 2009 12:25
Hola Federico,
Las principales diferencias son las siguientes:
1.- Se consigue una visualización diferente por FLTableDB en lugar de por tabla .mtd. Me explico, introduciendo la query en la propia tabla definimos siempre esa visualización de datos para todos aquellos puntos donde tengamos enlazada la tabla. Si, por ejemplo, a la tabla articulos.mtd le defino una query, en todos aquellos FLTableDB que tiren de artículos.mtd tendré siempre esa query mostrando los datos. De esta forma puedo conseguir diferentes vistas de los datos por cada FLTableDB (así, por ejemplo, los datos que me muestra el master de artículos, pueden ser diferentes a los datos que nos mostraría una consulta en el formulario de edición de proveedores para ver artículos de ese proveedor, por poner un ejemplo. En los dos casos tendríamos dos FLTableDB diferentes con dos qryVisualizacion diferentes atacando a articulos.mtd).
2.- No conseguí hacer funcionar la inserción, modificación o eliminación de registros en tablas que tenían un metadato query asignado. No sé si es que no se puede, o yo no encontré la forma, en cualquier caso, hice este pequeño desarrollo que me solucionaba el problema. Corrígeme, Federico, ¿es posible insertar, modificar o eliminar registros a partir de FLTableDB que muestran datos de una query (<query>) en lugar de registros de una tabla directamente?.
Por otro lado, estoy preparando otro pequeño cambio, con la creación de un nuevo widget de acceso a base de datos para buscar registros en una query o tabla relacionada, mediante un arbol jerárquico. Esto me va a ser especialmente útil en la implementación que estamos haciendo en AbanQ en mi empresa, una imprenta. La razón, el trabajo con papeles requiere una organización particular: Familias de papel -> Subfamilias de papel -> Papeles. Para facilitar al usuario (yo muchas veces!! jeje), la búsqueda, estaría bien disponer de un control que mostrara esta información a modo de TreeView, con nodos y tal. Tengo algo ya hecho en Qt4, pero voy a ver si soy capaz de implementarlo en Qt3 e integrarlo en AbanQ. Pregunto, ¿tenéis algo así para AbanQ v3? Si no es así, no me imporaría hacerlo siguiendo unas pautas para que os sea más sencillo (si interesa) integrarlo en el futuro AbanQ v3, ya en Qt4.
Saludos y gracias por la respuesta!
|
falbujer
Miembro |
# Publicado: 9 Mar 2009 17:29 · Editado por: falbujer
Hola David,
por fin tengo un rato para contestarte.
La consulta se puede filtrar desde los scripts, aplicando el filtro al objeto FLSqlCursor asociado a FLTableDB. Tambien puedes cambiar la propiedad tableName de FLTableDB, y defines tantas acciones como necesites para los distintos tipos de consultas que puedes mostrar en ese componente, en tiempo de ejecución cambias la propiedad tableName y consigues lo mismo. Con la ventaja que al usar acciones como nexo que engloba todo; la tabla, los scripts a usar y los formularios, manejas un concepto mas abstracto y general que sigue el patrón MVC, ya que en la acción no sólo tienes definida la consulta o tabla, sino también los formularios correctos que pueden manejar esos registros, así como los scripts que funcionarán bien con esa consulta y ese formulario, es decir existirán los campos que se esperan que existan y con los nombres correctos. De esta forma puedes hacer por ejemplo que un mismo formulario pueda funcionar con distintas consultas y tablas, siempre y cuando todas tengan la misma estructura de campos y nombres, pero que perfectamente pueden venir de distintas tablas y con datos distintos.
Esto por ejemplo lo usamos en algunas implementaciones donde la estructura de campos en pedidos, albaranes y facturas es exactamente la misma, y se puede usar un formulario idéntico para todos. Varios modelos ( datos ) y una única vista ( presentación o formulario).
Insertar se puede hacer, aunque nosotros no los usamos. Lo cierto es que siempre que podemos evitamos usar cursores generados de consultas, y creamos campos de almacenamiento, por temas de eficiencia sobre todo:
Algunos de nuestros clientes manejan base de datos muy grandes, por ejemplo en producción, se anotan tareas que pertenecen a procesos, y se muestra información del proceso y la tarea. Esa información se graba por el operario una sola vez y rara vez se modifica, se puede almacenar información en campos en vez de hacer el join.
Estamos hablando de consultas sobre tablas de 400.000 registros( que en algunos puestos de producción se repite decenas de veces por minuto cada vez que se registra el tiempo de una tarea ), y estos son los resultados de temporales de hacerlo de una manera u otra;
select count(*) from pr_tareas;
count
--------
387097
select count(*) from pr_procesos;
count
--------
219935
CON JOIN:
explain analyze SELECT tare.*,proce.* FROM pr_tareas tare inner join pr_procesos proce on tare.idproceso = proce.idproceso;
QUERY PLAN
-------------------------------------------------- -------------------------------------------------- -------------------------------------------------- ----------------
Merge Join (cost=29.41..33073.13 rows=387097 width=179) (actual time=0.140..3028.004 rows=387097 loops=1)
Merge Cond: (proce.idproceso = tare.idproceso)
-> Index Scan using pr_procesos_idproceso_m1_idx on pr_procesos proce (cost=0.00..9425.67 rows=219935 width=74) (actual time=0.071..448.147 rows=219935 loops=1)
-> Index Scan using pr_tareas_idproceso_m1_idx on pr_tareas tare (cost=0.00..18265.62 rows=387097 width=105) (actual time=0.058..870.154 rows=387097 loops=1)
Total runtime: 3551.346 ms
**************************
SIN JOIN:
explain analyze SELECT * FROM pr_tareas;
QUERY PLAN
-------------------------------------------------- -------------------------------------------------- -----------------
Seq Scan on pr_tareas (cost=0.00..11398.97 rows=387097 width=105) (actual time=0.027..604.680 rows=387097 loops=1)
Total runtime: 1099.243 ms
************************
Y por último, que me está saliendo un ladrillo. Ese widget ya existe, pero pienso que es mejorable, FLListViewInterface , FLListViewItemInterface.
Y ahora que lo dices nosotros hemos hecho una implementación para una empresa de artes gráficas, más bien en colaboración, la estamos ultimando y viendo la posibilidad de lanzarla por una asociación, puede ser ¿AIDO?, se ha encargado un compañero del proyecto y hablo un poco de oidas. Si te interesa escribeme a mail _ infosial . com y seguimos hablando.
Saludos.
|
dpinelo
Miembro |
# Publicado: 9 Mar 2009 18:03
Hola Federico,
Muchas gracias por la información. La pondré en práctica. De todas formas, parece que estábamos sincronizados, ya que a la vez que escribías este post, estaba yo ultimando una explicación "gráfica" de lo que se consigue con la modificación que introduje. ;-) Más o menos la idea que buscaba es la que planto en el post de mi blog
http://www.pinelo.com/blog/2009/03/09/ejemplo-prac tico-de-la-modificacion-mostrando-mas-informacion- en-los-stocks-de-abanq/
Por cierto, vaya post feo que me ha quedado, pero al menos se explica.
No he entendido del todo bien tu post: aunque la mejor manera de entender es ponerlo en práctica. Así que intentaré pondré en marcha lo que me comentas a ver si consigo el mismo resultado.
Por cierto, sí, es AIDO, una de las asociaciones más importantes en artes gráficas. Te escribo un correo, ya que me interesa mucho ese tema.
Muchas gracias por la respuesta y saludos.
|
montenk
Miembro |
# Publicado: 4 Ene 2010 01:39
Hola, me interesa particularmente el funcionamiento de FLListViewInterface pero estoy renegando bastante para rellenar el control desde QSA con los datos devueltos por una query. En la documentación de ABANQ no he encontrado nada referido a ello. ¿Podrían por favir darme los métodos para obtener el item actual, agregar nuevos subitems, etc? Muchas gracias, mientras sigo buscando.
|
klosll
|
# Publicado: 5 Ene 2010 15:06
Hola a todos
Al hilo de lo que comentaban Pinelo y Federico del tema de artes gráficas os puedo decir que en el plazo aproximado de par de meses tendremos la versión 1.0 de Abanq Gutten operativa con todas las partes enlazadas: presupuestos con selección de itinerarios óptimos de máquinas, seguimiento de la producción a través de terminales en planta y enlace con facturación (y contabilidad, por supuesto).
Efectivamente esperamos contar con el apoyo de AIDO, donde ya se han establecido contactos, para dar impulso definitivo a este proyecto.
Informaremos puntualmente de las novedades.
Un saludo,
Daviz Zafra
KLO Ingeniería Informática
Abanq Partner Gold
|
