FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Componente para maquillar DataModule
Hola Gente!
Alguien conoce algún juego de componentes que permita beautificar un Datamodule, de tal manera de poder hacerlo visualmente más entendible? Algo así como que se puedan agregar Groupboxes, etc. En fin... no sé si me explico, ojo que estos componentes no tendrían ninguna función en runtime. Tengo Datamodules que nacen chiquitos, pero al cabo de un par de años de desarrollo se hacen monstruosos... a pesar que también hay otros varios DMs interactuando. Saludos! |
#2
|
||||
|
||||
#3
|
|||
|
|||
Con Beautificar quiero significar embellecer, ordenar, etc.
Uso la palabra porque sé que existen "Code Beautifiers" que ordenan un poco el código, tabulados, etc. |
#4
|
||||
|
||||
Pero un datamodule es... eso, un módulo de datos, para añadir groupbox ya está el TForm.
No entiendo qué quieres "embellecer", ¿cambiarle colores?, ¿tipos de letras?, etc. |
#5
|
|||
|
|||
Bueno, haga un esfuerzo por entender...
Ya lo dije, quiero poner por ejemplo algún tipo de groupbox para meter adentro la tabla master y todas las nested de un objeto incluyendo el TQLquery, TProvider, TClientDataset y TDatasource y TImages si las tuviese. Y así para otros objetos persistentes en mi base, cada grupo con un color... De esta manera puedo hacer más entendible mi DataModule. Podría Poner un Group para los componentes de conexión. Los Popup menus en otro corralito, los action managers en otro. Y así podría de paso desarrollar mi parte artística... Última edición por mcbullrich fecha: 25-04-2012 a las 20:13:07. |
#6
|
||||
|
||||
malas practicas?
Tipico que tienes tus componentes de datos persistentes, es decir todos tus datasets y querys los llenas en tiempo de diseño, eso tiene sus limites en sistemas medianamente complejos, en donde cuando haces un pequeño cambio en las tablas (todo cambio es posible incluso en la data) tienes que volver a cambiar todo en tus componentes de dato en tiempo de diseño y ademas te llenas de datasets y querys en tu modulo de datos que ya no sabes como manejarlo. Solucion para esto: usa componentes de datos (datasets y querys) dinamicos que se llenen (y liberen) en tiempo de ejecucion, para eso tienes que programar todo explicitamente en el codigo, de otro modo ni tu ni nadie podra manejar tanto embrollo. Salu2.
__________________
nuestro carácter está reflejado en cada línea de código que escribimos. |
#7
|
||||
|
||||
Hola mcbullrich .
Perdón si es ignorancia, pero jamás oí de cosa tal como embellecer un TDataModule. Saludos.
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
#8
|
||||
|
||||
Cita:
|
#9
|
||||
|
||||
Cita:
Primero decir que no todas las propiedades enmarcadas en rojo tienen que ver con facilitar la organización de los objetos en los módulos de datos. Me pareció adecuado encerrar todas las que representan nuevas características respecto a los componentes nativos. De todas formas me gustaría disponer del tiempo necesario para explicar cada una de ellas, pero creo que por ahora me limitaré a las que competen al caso y un par más. Segundo, para evitar confusiones, decir que mi respuesta no es tanto para darle esto como solución a mcbullrich (ya quisiera yo tener estos componentes listos para varias versiones de Delphi), como sí para enriquecer el debate sobre esta inquietud que muchos comparten: la saturación "visual" de los módulos de datos (visual en el único tiempo en que un módulo de datos es visible: durante el diseño). Ahora, antes de entrar en materia, un poco de contexto "histórico" sobre la propiedades StoreActive e ImmediateApplyUpdates (antiguamente llamada ImmediateUpdates) de TMagiaClientDataSet: http://www.clubdelphi.com/foros/showthread.php?t=30633. Tómese en cuenta que ese hilo es de hace seis años, y desde entonces han cambiado tantas cosas en mi cabeza como en el código de las clases (creo que para bien). Lo traigo a colación por recordar la buena orientación que entonces me diste, Román. Gracias a las opiniones que entonces recibí pude tomar buenas decisiones sobre el diseño de ambas propiedades, las cuales pueden verse en la tercera imagen que subí. Viendo la segunda imagen podrán notar que también TMagiaSQLQuery tiene propiedad StoreActive. Y TMagiaSQLConnection y por tanto también su derivado especial para Firebird TMagiaFirebirdSQLConnection (primera imagen) tienen una propiedad de semejante funcionamiento llamada StoreConnected. Mientras se dejen en False estas propiedades, no serán guardadas en el DFM las propiedades Active y Connected, respectivamente, lo cual se traduce en que al ejecutar la aplicación esos objetos iniciarán cerrados (no intentarán abrirse por sí mismos). Así el programador se despreocupa de si dejó alguna conexión, consulta o conjunto de datos abierto en tiempo de diseño, teniendo mayor control sobre su apertura a través del código de la aplicación. Pasemos al meollo del asunto. Aunque los primeros mensajes de mcbullrich no están debidamente formulados, sí que hacen mella en quienes hemos usado los componentes que menciona: Cita:
Una pregunta importante era: ¿cómo hacer que el proveedor pueda contener cualquier clase de conjunto de datos (TSQLQuery, TADOQuery, etcétera)? La respuesta fue una propiedad de tipo String llamada InternalDataSetClass (segunda imagen). Con ella el programador indica de qué clase quiere que sea el conjunto de datos contenido (válido mientras la clase esté registrada). Nótese en la imagen que la propiedad nativa DataSet hace referencia a un objeto que pertenece, no a un módulo de datos, sino al propio componente proveedor: prContrato.DataSet. Es decir, al usar la propiedad InternalDataSetClass, el componente crea y guarda de forma interna un objeto de esa clase. Se puede notar que las "subpropiedades" de prContrato.DataSet son las de un objeto TMagiaSQLQuery (valor de las propiedad InternalDataSetClass). También podría ser un subcomponente ADO, ZeosLib, etcétera. No está de más decir que si esta propiedad de tipo String se deja en blanco, entonces en DataSet se puede asignar un objeto externo de la manera habitual. Otra pregunta que derivó de lo anterior fue: ¿cómo podrá ahora el programador definirle campos persistentes a ese conjunto de datos interno? Es de esperarse que si se le da doble clic a un TDataSetProvider no se abrirá el editor de campos, el editor de campos es para data sets. Bueno, pues con un poco más de programación conseguí que TMagiaDataSetProvider sí hiciera aparecer el editor de campos de Delphi al darle doble clic. En la imagen puede verse esa pequeña ventana con el título: prContrato.DataSet (los campos persistentes del conjunto de datos interno del proveedor prContrato). Bueno, eso fue por el lado de dmProveedor. Tengo que interrumpir esto por falta de tiempo, pero más adelante intentaré explicar lo que concierne a dmCliente. Por el momento, quien tenga experiencia con TClientDataSet y haya visto en la tercera imagen que además de la propiedad nativa ProviderName se tiene una propiedad llamada Provider, podrá inferir la utilidad de ésta cuando se trabaja en capas lógicas (o "2.5 capas"). Saludos y gracias por interesarte Román. Al González. Última edición por Al González fecha: 26-04-2012 a las 20:45:05. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Ayuda para instalar componente svqrbarcode para QReport | BlueSteel | Varios | 4 | 24-09-2010 23:05:23 |
Componente para buscar registros, para no repetir codigo. | flystar | Conexión con bases de datos | 9 | 28-04-2010 23:16:15 |
como mover todos los componente a un DataModule | kurono | Varios | 8 | 25-03-2008 02:09:45 |
Crear un DataModule para Firebird | claudiorene | Firebird e Interbase | 1 | 13-07-2007 18:01:09 |
componente para norma19 para delphi7 | raulmm26 | Varios | 3 | 07-02-2005 12:31:11 |
|