Co-creadores de Xailer. Especialistas en software de gestión para la PYME.

Fuentes de xaGeslite

xaGeslite es un programación de facturación básico realizado con Xailer y utilizando las técnicas más novedosas de programación, como son:

  • Herencia de formularios 
  • Enfoque vista-controlador 
  • Exportación de servicios desde xaGeslite
  • Importación de servicios desde otras aplicaciones como xaConta
  • Manejo de SQLite y fácil migración a cualquier otro entorno SQL

Los fuentes de xaGeslite constituyen en si mismo un estupendo esqueleto para el desarrollo de sus futuras aplicaciones. Incluso aunque el interfaz no sea de su agrado enseguida observará lo fácil que es modificarlo a su antojo sin perder toda la funcionalidad que ofrece el esqueleto de herencia de formularios.

El enfoque vista-controlador permite conseguir de una forma elegante y flexible los siguientes cometidos:

  • Reutilización de código al máximo posible
  • Simplificación de procesos complejos
  • Concentración de todo el código que depende del motor SQL
  • Importación y exportación de los servicios del controlador hacia otras aplicaciones

xaGeslite incorpora una completa sincronización con xaConta, de modo que las cuentas contables y terceros se crean y actualizan automáticamente y las facturas son traspasadas a la contabilidad sin necesidad de realizar ningún proceso de importación en xaConta. Todo ello se realiza a través de los servicios que exporta xaConta en forma de DLL, de forma que xaGeslite no tiene porque saber ni siguiera con que base de datos se está conectando para hacer la sincronización.

Si desea utilizar xaConta como software de Contabilidad para sus futuros clientes, el código suministrado de los fuentes de xaGeslite le puede ser de gran utilidad para conectarse desde sus aplicaciones de gestión con xaConta.

Se entregan el 100% de los fuentes de programación y tendrá derecho a utilizar los mismo en cualquiera de sus proyectos. No obstante, no podrá incluir en sus aplicaciones los fuentes de programación de las mismas si estas tienen código derivado de xaGeslite.

Los fuentes están ampliamente documentados y son auto-explicativos. No obstante, ante cualquier duda referente a los mismos podrá hacernos una consulta en el foro.

Nota Importante
xaGeslite exige un alto conocimiento de Xailer, programación orientada a objetos y manejo de bases de datos SQL.  Por dicho motivo no se atenderán más 10 consultas técnicas por usuario, a no ser que entendamos que las preguntas son técnicamente avanzadas y pueden ayudar al resto de usuarios.

Los fuentes de xaGeslite requiere la utilización de Xailer 2.0 para su correcto compilado y enlazado.

OZ Software está abierto a la colaboración con cualquier desarrollador avanzado que desee utilizar el sistema propuesto por xaGeslite para crear y comercializar programas de forma conjunta que puedan cubrir necesidades de gestión estándar o de sectores verticales. 

Características principales de su diseño

El diseño de xaGeslite se ha basado en varios pilares:

  • Herencia de formularios
  • Máxima utilización del diseñador visual de Xailer
  • Enfoque vista-controlador
  • Exportación e importación de servicios
  • Uso de SQLite como gestor de base de datos

Herencia de formularios:

xaGeslite utiliza cuatro formularios base de los cuales heredan absolutamente el resto de formularios de la aplicación, que son:

  1. TFrmMainMaster
  2. TFrmFolder
  3. TFrmInput
  4. TFrmPrint

Todas las clases están planteadas para que absolutamente sin ningún cambio se puedan utilizar en nuevos proyectos o incluso se realice una librería con las mismas.

La definición de clases no incluye en ningún caso la existencia de un formulario asociado al mismo, es decir, se trata de sobrecargar la funcionalidad de las clases bases de Xailer, pero en ningún caso se añade ningún elemento visual, ya que la parte visual de los formularios siempre se encuentra en los formularios finales (últimos en el nivel de herencia). De esta forma, evitamos la actual limitación de Xailer, que carece de herencia visual de formularios, pero sin embargo obtenemos prácticamente los mismos beneficios.

TFrmMainMaster recoge absolutamente toda la funcionalidad básica que tiene la aplicación, como por ejemplo:

  • Procesos de arranque y cierre de la aplicación
  • Persistencia de la configuración de usuario
  • Procesamiento de teclado para operaciones generales a la aplicación
  • Ejecución de procesos
  • Conexión con módulos externos
  • Selección de empresa
  • Gestor de ayuda en línea

El formulario principal de la aplicación (TFrmMain) hereda directamente de TFrmMainMaster y de esta forma conseguimos que su código se reduzca a la mínima expresión. De hecho no llega a más de 250 líneas de código y todo su contenido es tremendamente fácil de entender. Todo el diseño visual se encuentra en dicho formulario y se realizado completamente a través del diseñador de formularios del propio Xailer.

  

El formulario principal de xaGeslite incluye como elementos principales:

  1. un objeto 'Tmenu' 
  2. una 'TRebar' con dos objetos 'TToolbar' 
  3. una 'TExplroerBar' con tres 'TOptionList'
  4. un objeto 'TFolder'

¡Eso es todo! Lo más relevante es que todos los elementos de la 'TExplorerBar' son compartidos por las distintas opciones de la aplicación.  De esta forma conseguimos reducir al máximo el consumo de recursos y limitamos la creación de controles de forma importante. Lo cual contribuye a que la aplicación sea tremendamente ágil incluso en máquinas poco potentes como un 'Netbook'. Los elementos de las 'TOptionLists' se actualizan de forma automática al cambiar de pestaña en el objeto TFolder sin que sea posible apreciar el menor parpadeo en la operación y todo ello, sin que el programador tenga que preocuparse de su diseño.

TFrmFolder es la clase base que se utiliza para mostrar las distintas páginas de un control TFolder del formulario principal. En xaGesLite se ha pretendido la mínima utilización posible de formularios modales, utilizado la técnica de mostrar cada formulario no modal como una página dentro de un objeto TFolder. Por lo tanto, todos los formularios no modales de la aplicación heredan de TFrmFolderPage y automáticamente se convierten en páginas de un objeto TFolder y no en un formulario corriente que heredase de TForm.

La clase TFrmFolder ofrece muchísima funcionalidad básica a cualquier página del objeto TFolderPage, como:

  • Ampliación de la funcionalidad de su clase base para soportar eventos típicos del formulario, como OnInitialize, OnSize y OnClose.
  • Persistencia de la definición de columnas (tamaño y visibilidad) de todos los objetos 'TBrowse' de los distintos módulos
  • Adaptación automática de las TOptionLists del formulario principal a la pestaña visible
  • Existencia de métodos virtuales para todas las operaciones clásicas de mantenimiento
  • Métodos básicos por defecto para construcción automática de las listas de opciones para las 'TOptionsLists'

La clase TFrmFolder contiene métodos virtuales para las operaciones clásicas, como por ejemplo, 'AddRecord()' y además posee el método SetOptionLists() que es el que establece las opciones por defecto en la 'TOptionList'. Cualquier formulario que herede de TFrmFolder tan sólo necesitará sobrecargar los métodos virtuales que necesite. Un ejemplo:

METHOD AddRecord() CLASS TFldArticulos

RETURN TFrmArticulos():New( ::oFrmMain, ::oRSMain ):Append()

Como puede observar el alta de artículos se hace con una sola línea de código. En seguida veremos como.

Para lanzar una nueva página desde el formulario principal es igual de sencillo:

METHOD BtnFacturas( oSender ) CLASS TFrmMain

    ::OpenFolderPage( "Facturas" )

RETURN Nil

El diseño completo de la página del folder se hace como un formulario más con Xailer, tan sólo hay que tener la precaución de heredar de TFormFolder en vez de TForm:

TFrmInput es la clase base encargada de todos los formularios tipo ficha, en los cuales se hacen las clásicas operaciones de altas y edición. Esta clase hereda directamente de TForm y se encarga de añadir las siguientes funcionalidades a la clase TForm:

  • Método Append() para realizar altas estándar
  • Método Edit() para realizar ediciones estándar
  • Asignación automática del dataset a todos los datacontrols del formulario
  • Nuevos métodos PreAppend, PostAppend, PreEdit y PostEdit para poder realizar operaciones adicionales e incluso parar el proceso de alta o edición si fuese necesario
  • Establece valores por defecto del formulario

Todos los mantenimientos de tablas de la aplicación se han realizado utilizando esta clase base sin que haya habido necesidad siquiera de sobrecargar el método Append() o Edit() que como supondrá es perfectamente posible.

Y por último se utiliza la clase base TFrmPrint cuya única misión es establecer los valores por defecto del formulario. 

Otra de las grandes ventajas de utilizar clases bases es que las tareas de modificar el comportamiento o funcionamiento de la aplicación en la mayoría de los casos es posible realizarlo en las clases base, por lo que cambiando cualquiera de ellas, cambia el comportamiento de todos los formularios que dependen de ellla.

Máxima utilización del diseñador visual de Xailer:

Efectivamente así es. Ningún formulario de la aplicación está creado directamente por código, ni siquiera parcialmente. Como se ha explicado anteriormente, las formularios base no contienen ningún diseño visual

Enfoque Vista-controlador:

xaGeslite propone un enfoque vista-controlador simplificado en el cual básicamente se separan la capa de presentación y la capa de negocio que entendemos es el más adecuado para poder seguir utilizando al máximo la potencia RAD que ofrece Xailer.

Toda la capa de negocio de la aplicación es sustentada por una o varias clases que ofrecne todos los servicios que pudiésemos necesitar. En el caso de xaGeslite dicha clase tiene el nombre de 'TGesLiteServicios' y en toda la aplicación existe una variable de tipo pública de nombre 'oSrv' que no es más que una instancia de dicha clase. 

A modo de ejemplo, os mostramos el prototipado de la clase:

CLASS TGesLiteServicios FROM TComponent

   CLASSDATA hContaDLL INIT 0 READONLY
 
   DATA oDSEmpresa, oRSConfig, oContaSrv
   DATA cUserName, cErrorMsg, cWarningMsg, cContaFile
   DATA lShowErrors, lShowWarnings, lShowInfo
 
   ACCESS Periodo  INLINE ::oRsConfig:Periodo
   ACCESS Empresa  INLINE ::oRsConfig:Nombre
   ACCESS SerieFac INLINE ::oRsConfig:SerieFac
   ACCESS Fichero  INLINE ::oDsEmpresa:cConnect
   ACCESS oDSConta INLINE ::oContaSrv:oDSEmpresa
 
   METHOD New( cFile )
   METHOD End()
 
   METHOD ShowError( cOperation, oError )
   METHOD ShowWarning( cMsg )
 
   METHOD DatasetClientes( oDataset )
   METHOD DatasetArticulos( oDataset )
   METHOD DatasetFacturasPorFecha( oDataset, dFecIni, dFecFin, lCerradas )
   METHOD DatasetFacturasPorNumero( oDataset, cSerie, nFacIni, nFacFin, lCerradas )
   METHOD DatasetMovArtPorFecha( oDataset, dFecIni, dFecFin )
   METHOD DatasetMovCliPorFecha( oDataset, dFecIni, dFecFin )
 
   METHOD ArrayGrupos()
   METHOD ArrayTiposIva()
   METHOD ArraySectores()
   METHOD ArrayFormasDePago()
 
   METHOD HayFacturasCliente( cClienteID )
   METHOD HayFacturasArticulo( cArticuloID )
   METHOD HayArticulosConIva( cIvaID )
   METHOD HayArticulosConGrupo( cGrupoID )
   METHOD HayClientesConFPago( cFPagoID )
   METHOD HayClientesConSector( cSectorID )
   METHOD HayConexionConta() INLINE ::oContaSrv != NIL
 
   METHOD NuevaFactura() INLINE ;
          TGesLiteFactura():New( Self )
   METHOD CargaFactura( cSerie, nFacturaID ) INLINE ;
          TGesLiteFactura():New( Self, cSerie, nFacturaID )
   METHOD BorraFactura( cSerie, nFacturaID )
   METHOD CierraFactura( cSerie, nFacturaID, lConta )
   METHOD TraspasaFactura( cSerieID, nFacturaID )
   METHOD TraspasaCliente( xCliente, oTercero )
 
   METHOD GetSiguienteFacturaID( lSave, lTrans )
   METHOD GetClienteInfo( cCodigo, lAsDataset )
   METHOD GetClienteFacturas( cCodigo, dFecIni, dFecFin )
   METHOD GetSiguienteClienteID()
   METHOD GetArticuloInfo( cCodigo, lAsDataset )
   METHOD GetSiguienteArticuloID()
   METHOD GetFacturaCabInfo( cSerieID, nFacturaID, lAsDataset )
   METHOD GetIvaInfo( cArticuloID )
   METHOD GetIvaConta( nIvaID )
   METHOD GetFPagoInfo( nFpagoID )
 
   METHOD BuscaArticuloConMov( cArticID, nDir, dIni, dFin )
   METHOD BuscaClienteConMov( cClienteID, nDir, dIni, dFin )
 
   METHOD ListadoVentasSectores( dFecIni, dFecFin )
   METHOD ListadoVentasGrupos( dFecIni, dFecFin )
 
END CLASS
 
Observe como para crear toda una factura tan sólo hay que llamar al método NuevaFactura() y como seguro que ya habrá intuido para grabar dicha factura tan sólo hay que llamar a su método 'Save()', al igual que para imprimirla tan sólo hace falta llamar a su método 'Print()'.
 
Las ventajas de utilizar este modelo son tremendas:
  • Todo el código SQL se encuentra unificado en muy pocos módulos, por lo que es relativamente sencillo adaptar las clases del controlador a cualquier otro motor de bases de datos que se requiera. Incluso sería posible y con muy poco esfuerzo utilizar técnicas de compilación condicional para que el mismo código fuente sirviese para más de un motor de bases de datos.
  • El trabajo complicado de análisis y gestión de los datos de la aplicación puede ser realizado por el personal más cualificado, permitiendo delegar las operaciones de diseño de formularios e informes a personal con menos experiencia.
  • Reutilización al máximo de código ya que al utilizar este enfoque de programación, cualquier requerimiento de manejo de datos se ha de hacer en el contralador y por tanto pasa a ser susceptible de ser usado en otros procesos. Además, en cuanto se comienza a desarrollar de esta manera se tiende de una forma natural a cada vez que se añade una nueva funcionalidad al controlador, se intenta preveer futuros usos, por ejemplo ,añadiendole parámetros que a lo mejor en un primer momento no son necesarios pero que se intuye pueden ser muy útiles en el futuro.
  • El controlador es susceptible de ser usado no sólo en nuestra aplicación, sino que puede ser llevada fácilmente a otros proyectos, como sería por ejemplo un CGI para su utilización en el desarrollo de páginas Web. Para ello, es muy importante que el contralador sea completamente independiente de la aplicación. Es una tarea realmente sencilla crear un nuevo proyecto del tipo DLL que sólo incluya las clases del controlador y de esta forma podamos utilizar dicha DLL en otros proyectos como podría ser una aplicación TPV. De esta forma resolveriamos el problema de creación e impresión de facturas desde el TPV de un plumazo.

xaGeslite utiliza una técnica simple y elegante de conjuntar el sistema de programación RAD junto con el enfoque vista-controlador que se puede observar claramente en sus fuentes. 

Exportación e importación de servicios:

Como hemos visto el enfoque vista-controlador nos permite exportar sin problemas todos los servicios que ofrece en forma de DLL para ser utilizado en otros proyectos. Pero por el mismo motivo también se pueden importar los servicios ofrecidos por otra aplicación.

Este el caso de xaGeslite que se apoya en los servicios de xaConta para hacer una sincronización absoluta con la misma. Para ello simplemente es necesario que la librería xaConta.DLL se encuentre en el directorio de la aplicación xaGeslite y que lógicamente configure la empresa para indicarle la ubicación de la base de datos de la empresa en xaConta.

Uso de SQLite como gestor de base de datos:

xaGeslite utiliza como único motor de base de datos SQLite y entendemos que sus fuentes de programación son un estupendo tutorial de como progamar para dicha base de datos. 

Observará que se utilizan desde las sentencias SQL más simples a las más complicadas pero siempre intentando hacerlo con la mayor claridad posible.

[El equipo de OZ Software]