Generador de formulario tipo ABM (CRUD)

[Víctor Hugo Espínola Domínguez]

Hola colegas

Estoy empezando un proyecto para facilitar el desarrollo de nuestras aplicaciones, un framework básico, hasta ahora tengo la primera versión del generador de formularios tipo ABM (CRUD). 

 

El formulario "GenerarForm.scx" genera formularios tipo ABM (CRUD) tomando como punto de partida la tabla a la que se dará mantenimiento. La misma puede estar alojada en una base de datos nativa o en un SGBD cualquiera, en esta versión está implementada la conexión a DBC de Visual Foxpro y  Sql Server 2005 o más reciente.

El formulario generado puede validar y exhibir datos que representan claves foráneas, las cuales pueden ser simples, recursivas y múltiples a una misma tabla relacionada. 

Puede insertar o cambiar imágenes, fotografías guardadas en la tabla.

Tiene implementado un sencillo buscador de hasta 4 campos, y trabaja con el esquema de Cliente/Servidor. Al inicio muestra la pantalla vacía y se trae mediante el buscador un solo registro que puede ser editado o eliminado.

El acceso a datos se efectúa casi totalmente mediante la clase Cursor Adapter y no se usa Store Procedure alguno para garantizar la portabilidad entre SGBDs.

Pueden bajarlo del siguiente enlace: http://www.mediafire.com/download.php?qt7kyc8mo205arm

El archivo "LeemeGenForm.rtf" ( Word o WordPad ) contiene una guía básica del funcionamiento del formulario.

Saludos,

Víctor.

[Rodolfo Arias]

Muchas gracias Víctor.

[Analyzer]

Gracias Victor,

Le daré un vistazo al código ya que me parece muy interesante la forma en que programas.

Framework de VFP?... Interesante iniciativa.

Saludos!

[Analyzer]

Lastima.. El antivirus me marca que el archivo LeemeGenForm.rtf es una bomba de descompresión.

Ni modos... se fue directo a cuarentena..

Saludos!

[Víctor Hugo Espínola Domínguez]

Ahí va en formato pdf

Saludos,

Víctor.

[Analyzer]

Gracias Victor Hugo! 

Eres muy amable amigo..

Saludos!

[Claudio Luna]

Victor,

Muchas gracias por el aporte.

Un abrazo

--

Claudio Luna

Monttevideo - Uruguay

SKYPE: clunamarin

Cel. 099 194 770

[ZeRoberto]

Veo que aun conservas los iconos del Windows 98

Saludos

--
btnMyVideo.Click()

[Carlos Miguel FARIAS]

Hay varios frameworks para vfp.
Promatrix.com, y otros para mas o menos lo mismo.
En mi caso. Para los abm utilizo un sistema de clases heredadas para la funcionalidad básica.
No me parece apropiado (y eso es un criterio personal) que el formulario se ate a la estructura de la bd. Ya que la interfaz debe ajustarse al dispositivo de entrada/salida mas lento y sujeto a errores (y de funcionamiento impredecible) a la que se conecta la aplicación. A los fines de optimizar esa parte. Estoy hablando del operador humano del programa.
Saludos: Miguel, La Pampa (RA)

[Víctor Hugo Espínola Domínguez]

Hola Carlos Miguel

>Hay varios frameworks para vfp.
>Promatrix.com, y otros para mas o menos lo mismo.

En mi búsqueda de un framework para mi uso probé los siguientes:

- Codebook: muy bueno pero se estancó en VFP6, Ricky De Castro lo actualizó para VFP9.

- Tier Adapter: también muy bueno pero se truncó apenas nacer.

- Frameroot: buenísimo, empecé un proyecto para mi uso particular, pero no me gustó el estilo de sus ABM

- Visual Promatrix: excelente, es el mejor por mucho entre todos.

Actualmente mi actividad principal no está ligada a la profesión informática, pero en mis ratos libres, muchos más de lo que me hubiera gustado, estoy migrando una aplicación que empecé en dBase II con una Commodore 128 y la terminé con FPD 2.0 en una PC XT hace más de 20 años, aún la siguen usando pero como nunca falla no me reditúa beneficio alguno.

Mi participación en este foro es más para ejercicio mental, como una terapia preventiva para que en un futuro muy cercano no me olvide donde dejé la botella de vino, disculpa por apropiarme de tu frase  ;- ).

El proyecto que estoy compartiendo con el grupo es principalmente con fines pedagógicos para los compañeros que recién están empezando a lidiar con la POO ( clases visuales y definidas por código ), no pretendo desarrollar un framework completo, solamente la parte de generación de formularios y quizá la de administración de usuarios.

>No me parece apropiado (y eso es un criterio personal) que el formulario se ate a la estructura de la bd.

No entendí muy bien esta frase, pero "GenerarForm.scx" está atado a la estructura del cursor generado desde la tabla, independientemente del origen de los datos, DBC o SGBD, y es para uso del programador, no del operador humano del programa.

Saludos,

Víctor.

[Carlos Miguel FARIAS]

Cuando digo formularios atados a la tabla/s es cuando la distribución de los campos responde a el orden de las propiedades dentro de cada una de las tablas sobre las que haces el ABM o CRUD.

Cuando es una simple tabla, posiblemente no haya alternativas apropiadas, o como lo planteas para fines didacticos, evidentemente no hay mejor opción (occam).

En el caso de formularios de baja utilización (tablas muy estáticas) posiblemente, no se justifique otra solución que la que planteas.

Pero en cargas relativamente complejas, con muchos datos, o con necesidad de consultas intercaladas no manejables por un simple popup, creo que el diseño debe ajustarse en función de la comodidad y eficiencia del operador del sistema.

En algunos casos además, si una entrada para el usuario, que puede resultar en algo directo (abm clientes, proveedores, etc.) o que ve como una unidad, el modelo de datos subyacente puede ser complejo.

Por ejemplo, en mi caso, tengo una tabla de personas, con los datos genéricos, a su vez, en una relación 1 a 1, tengo datos especificos de clientes en una tabla, y de proveedores en otra.

Personas = {idPersona, cApellido, cNombres, idDirPostal, [...]}

Clientes = {idPersona, idDirEnvio, yLimiteCredito, yDeudaAnterior, [...]}

Proveedores = {idPersona, idDirLocal, iCalifica, [...]}

(aca pueden ir otro tipos de personas, como Médicos, Obras Sociales, Estudiantes, Profesores, Empleados, etc.)

DocIdentidad = {idPersona, cTipoDoc, nDocumento}

Direcciones = {idDireccion, cCodPostal, cCodCalle, nPuerta, [...]}

(negrita: primarias, italica: foráneas)

En el modelo anterior, entre personas y las otras tablas con datos de clases de personas específicas, hay una relación 1 a 1, es un tipo de modelo OO.

Y permite que una misma persona pueda ser proveedor y cliente a la vez, y si me cambia su dirección postal, automaticamente el modelo, propaga la actualización a todas las formas en que esa persona figura en el sistema.

Y además se preve multiples documentos de identidad (CUIT, CUIL, Legajo, Libreta Estudiante, Matriculas Profesionales, etc.).

Y todas las direcciones están sistematizadas en un mismo lugar, y una persona, puede tener más de una, o ser la misma, pero con diferente denominación.

Y evidentemente, un modelo así, no se lo podes presentar al usuario tal cual, por limitaciones en la capacidad del operador, y/o limitación o claridad en la interfaz que se arme para cargar y VALIDAR los datos.

Reitero, a los fines académicos, un modelo simple, es totalmente válido, lo importante no es en este caso, como hacer un modelo útil en todos los casos, si no, un modelo entendible, ya que el fin, es aprender a usar el fox y no diseño de sistema.

Saludos: Miguel, La Pampa (RA)

[Víctor Hugo Espínola Domínguez]

Hola Carlos Miguel

La idea original de Les Pinter era dar un ejemplo de programación en 3 capas con Visual Foxpro, con énfasis en la capa de negocios y la capa de datos. Tanto es así que para la capa cliente usó las tablas "Customers" y "Employees", que son excelentes ejemplos de como NO diseñar datos, y a la clase form la llamo "FlatFileForm" ( formulario para tabla plana ). Para que no quede tan simplote yo le agregué a la tabla "Customers" los campos para guardar la foto y el campo "EmployeeId" clave foránea referente a la tabla "Employees".

Por lo tanto las mencionadas tablas no deben ser tomadas como paradigma de diseño de tablas, sino todo lo contrario como ya lo señalé en el párrafo anterior.

Ahora bien, las clases de controles y formularios de la biblioteca "Pinter.vcx" si son buenísimos ejemplos y también la clase "DataTier" para los que prefieren Sql Pass-through  a los Cursor Adapters.

La modificación que le hice a la clase "FlatFileForm" fue sustituir la técnica Sql Pass-through  por la del uso de Cursor Adapters, y la clase "FkForm" ( foreign key form ) está basada en la clase "FlatFileForm" y permite validar claves foráneas y exhibir los datos descriptivos correspondientes.

En cuanto al diseño de formularios para estructuras de datos más complejas yo diría que es una cuestión de gustos, tanto del programador ( en muchos casos deficiencias del programador ) y del usuario. Por ejemplo para cargar las direcciones de las personas algunos preferirían que se haga en una página de un pageframe, otros quizás prefieran que se haga en un formulario independiente llamado al pulsar un botón y otros querrían ver en la misma pantalla el grid correspondiente.

En el diseño de datos concuerdo totalmente con tu modelo, el mío es más complejo en algunas cosas y más sencillo en otras. En mi sistema de venta de lotes, tengo Persona, Empresa, Condominio y la dirección de la persona es un campo en Persona y otro en Empresa pudiendo una persona tener actividad laboral en más de una empresa. El cliente puede ser una persona, empresa o condominio y el condominio puede estar formado por personas y/o empresas.

Saludos,

Víctor.

[Carlos Miguel FARIAS]

Les Pinter, me suena, no es ese que demostró que migrar de VFP a VB.NET era lo mejor

(para romperse los cuernos escribiendo el doble)?

Los FlatFileForm, los viernes se transforman ponen lentos y por ende insorpotables...
? STRTRAN("FlatFileForm", "FileForm", "ulentos")

Saludos: Miguel, La Pampa (RA)

[Analyzer]

CMF,

Sabe donde puedo ubicar el artículo sobre migrar a .net de Les Pinter?..

O fue en alguna conferencia..

Quiero ver ese código..

Saludos!

[Víctor Hugo Espínola Domínguez]

Hola Carlos Miguel

Si alguna vez lo hizo, muy pronto se disculpó: http://www.universalthread.com/ViewPageArticle.aspx?ID=886

Fíjate en el último párrafo ;-)

Saludos,

Víctor.

[Analyzer]

Gracias Victor Hugo,

El artículo es interesante. Saco como conclusión que VFP es mucho más fácil de usar.

El artículo es de marzo de 2007. Creo que vs 2010 (es lo que pienso usar) ya debe tener mejoras.

Para las aplicaciones de escritorio que requiero (aquellas donde el cliente exige usar una herramienta con continuidad) sigo viendo a vb.net como mi mejor opción (el C# ese no me gusta). Para lo poco que he tocado vb.net no tiene mayor complicación.

Para aplicaciones web, opté por php.

Para escritorio (donde al cliente le importa la funcionalidad y el tiempo de entrega y no tanto la herramienta de desarrollo), seguimos con VFP9 SP2.

Saludos!

[Carlos Miguel FARIAS]

Víctor: Tienes razón, yo lo decía con sarcasmo, porque justamente casi todos los ejemplos daban a entender que con VB.NET tenía que trabajar como loco.

Ultimo párrafo traducido:

"Así que aquí está mi confesión: La mejor herramienta para la gestión de los innumerables detalles de una conversión de FoxPro a VB.NET es ... FoxPro. Es rápido, potente, intuitiva y fácil de aprender. De hecho, es como que hace que te preguntes por qué va a convertir la aplicación para empezar."

Y es algo que M$ no le importó a VFP desetimó.
Saludos: Miguel; La Pampa (RA)

[Víctor Hugo Espínola Domínguez]

Hola colegas

Está disponible para la descarga la versión 2 del generador de formularios ABM, se le agregó la capacidad de validar claves candidatas.

Enlace: http://www.mediafire.com/?h784bbor5brkbej

Saludos,

Víctor.

[Jose Mario]

me gusto esto

Mi participación en este foro es más para ejercicio mental, como una terapia preventiva para que en un futuro muy cercano no me olvide donde dejé la botella de vino, disculpa por apropiarme de tu frase 

[Jairo Miranda]

Es necesario registrarce en mediafire?

JM

[Víctor Hugo Espínola Domínguez]

No

Saludos,

Víctor.