Durante largos años los cientos de miles de usuarios de Clipper en todo el mundo han estado esperando una solución real, fiable y práctica a uno de sus principales problemas: la migración a Windows. Durante este tiempo, hemos asistido a un desfile de propuestas que, por una razón u otra, no han acabado de satisfacer a los programadores de este lenguaje tan extendido. CA-Visual Objects, la solución de Computer Associates que debería haber sido la vía natural de migración, no ha cuajado como era de esperar, debido a su compleja sintaxis, a la limitada compatibilidad con Clipper y, porque no decirlo, al escaso interés que ha mostrado Computer Associates por este producto.
Otras alternativas, como FiveWin y Clip4Win, que pretenden atacar el problema desde el punto de vista de la compatibilidad como premisa, no son más que una simple extensión a lo que Clipper es capaz de ofrecer y, si bien permiten aprovechar buena parte del código, también heredan las limitaciones de un producto como Clipper concebido para entornos DOS. Aunque su utilización proporciona una rápida migración a Windows (de 16 bits, por supuesto), su evolución posterior resulta complicada, dado que la arquitectura y el compilador en el que se basan no es el más adecuado.
De hecho, muchos de los antiguos usuarios de Clipper han descartado definitivamente sus aplicaciones DOS optando por empezar de nuevo, ya sea utilizando un lenguaje xBase para Windows, como Visual FoxPro, o adoptando un nuevo entorno de desarrollo radicalmente diferente, como Delphi o Visual Basic. Superado el largo período de aprendizaje de estas herramientas, es evidente que los nuevos desarrollos se ajustan mucho más a la actual demanda de las empresas y usuarios. Pero la transición siempre resulta difícil, y no son pocas las compañías de desarrollo que han padecido, e incluso sucumbido, ante este cambio.
La causa de la desesperación de los todavía programadores de Clipper se centra en qué hacer para evolucionar sus programas DOS y entrar en el mundo Windows antes de perder su actual base instalada. En ABOX recibimos llamadas y mensajes a diario solicitándonos consejo sobre este tema, y cuya respuesta no resulta evidente… por lo menos hasta ahora. Y es que, a pesar de que la petición se puede resumir en un simple «queremos un Clipper para Windows», ninguna de las soluciones anteriormente expuestas se ajustan a este enunciado.
Hace algo más de un año, tuvimos noticia de la disponibilidad de una herramienta compatible con Clipper y que permitía crear aplicaciones para OS/2. Dada la escasa implantación de OS/2 en nuestro país, no le prestamos una atención excesiva, a pesar de que sus características resultaban prometedoras. Esta herramienta es Alaska Xbase++ y, por fortuna para los usuarios de Clipper, está disponible para Windows NT/2000/XP y 95/98/ME.
Ante el gran potencial de este producto decidimos contactar con Alaska, la empresa alemana creadora del producto, para recabar más información sobre el mismo y solicitar su distribución en España. Durante el mes de noviembre pasado, recibimos la visita del director de marketing de Alaska, Jürgen Zugck, quien nos comentó en detalle las características actuales y futuras de Xbase++, y de su propia empresa. En más de una ocasión, nos hemos encontrado con fabricantes de utilidades que cuentan con tan solo uno o dos programadores. Nos sorprendió gratamente que el equipo de desarrollo de Xbase++ estuviera formado por más de diez personas (muchas más de las que dispone Computer Associates para Clipper y Visual Objects), y el compromiso que Alaska ha adoptado para ir añadiendo mejoras al producto en los próximos meses. Curiosamente Xbase++ es un producto maduro, ya que la primera versión vio la luz en el año 1993. Funcionaba sólo bajo OS/2 por una razón muy simple: OS/2 era el único sistema operativo de 32 bits disponible por aquel entonces. El éxito que ha tenido el producto en su país de origen, y el gran interés despertado a escala mundial en los diferentes foros dedicados a Clipper, nos hacen concebir grandes esperanzas sobre Xbase++.
Pero, ¿qué es Xbase++ y qué lo diferencia del resto de alternativas ofrecidas hasta la fecha? La respuesta es inmediata: Xbase++ es un auténtico y eficaz compilador del lenguaje Clipper para entornos gráficos. No se trata de una utilidad que añada algo a Clipper para hacerlo funcionar bajo Windows, sino de un nuevo compilador totalmente reescrito y adaptado a los nuevos GUIs. Es obvio indicar, por tanto, que no se requiere Clipper, dado que Xbase++ incluye su propio compilador y enlazador. Por otra parte, Xbase++ respeta la sintaxis de Clipper a la hora de desarrollar aplicaciones, lo que garantiza la compatibilidad del código escrito y su progresiva adaptación a las interfaces gráficas. Pero veamos en detalle todo lo que nos ofrece este producto.
Xbase++ es compatible al nivel de lenguaje con CA-Clipper, desde la versión Summer 87 hasta la 5.2e. Si bien se requieren pequeños cambios en el código relacionados con el trabajo bajo un entorno gráfico, éstos son mínimos y están perfectamente documentados. La migración de aplicaciones Clipper es, por tanto, muy sencilla. Asimismo, se ofrece un cierto grado de compatibilidad con el código Xbase de otros dialectos, como FoxPro o dBASE, aunque no es total.
Es de agradecer que Xbase++ soporte características como el preprocesador, los codeblocks y la evaluación de macros, tan habituales en los programas Clipper. Asimismo, su arquitectura de tres capas permite utilizar tres elementos característicos en programación: comandos, funciones y objetos. Dispone de una total libertad a la hora de utilizar cualquiera de estos elementos y adoptar el modelo de programación que más le convenga, ya que el compilador transforma comandos, funciones y objetos de forma transparente.
Naturalmente, se ofrece un completo soporte de los comandos propios de Clipper. Una aplicación tan simple como la siguiente:
– USE CLIENTES INDEX CODIGO BROWSE( )
muestra una pantalla «browse» típica con la base de datos seleccionada.
Puesto que la función BROWSE( ) es propia del modo texto, esta pequeña aplicación mostraría una ventana propia de Windows con el browse en formato texto. De hecho, al compilar con Xbase++ se obtiene una auténtica aplicación Windows, aunque su aspecto recuerde la emulación de un programa DOS. Una simple modificación al código anterior permite disponer de un browse gráfico, propio de Windows:
– USE CLIENTES INDEX CODIGO APPBROWSE NOMBRE, APELLIDO, DIR, POBLACION
El comando APPBROWSE, incluido en Xbase++ como una alternativa a BROWSE( ), facilita la rápida y simple adaptación de las aplicaciones a un entorno gráfico.
Todos los comandos se traducen a funciones mediante el preprocesador de Xbase++. Puede combinar libremente comandos y funciones, por lo que el programa anterior podría escribirse de la siguiente forma:
DbUseArea(«CLIENTES»)
DbSetIndex(«CODIGO»)
APPBROWSE NOMBRE, APELLIDO, DIR, POBLACION
El último nivel de la sintaxis corresponde a los objetos. Xbase++ implementa un modelo de programación orientado a objetos con todas las características propias de este paradigma: declaración de nuevas clases, herencia múltiple, encapsulación y polimorfismo. Aunque el uso de este modelo no es obligatorio, el hecho de haber sido incluido en Xbase++ representa disponer de la posibilidad de utilizarlo una vez finalizada lo que podríamos llamar la migración básica. Con ello, está en sus manos aprovechar todas las ventajas propias de la orientación a objeto en sus desarrollos. Naturalmente, clases bien conocidas en Clipper, como Get y Tbrowse, están disponibles dentro de la jerarquía de Xbase++, y puede heredarse a partir de ellas para crear subclases.
Si Xbase++ se distingue por algo es por la facilidad que ofrece para la transición de las aplicaciones a un entorno gráfico. Así como en CA-Visual Objects resultaba prácticamente obligatorio volver a escribir o diseñar la interfaz de usuario, en Xbase++ el cambio de los controles DOS a sus homólogos en Windows resulta mucho más directo. Pero no sólo eso, sino que el paradigma del control de eventos propio de Windows se oculta (o encapsula, siguiendo la terminología de orientación a objeto) bajo el modelo de clases de Xbase++, transformándolo en un modelo de manejo de eventos mucho más simple y flexible. Este modelo facilita la migración de una aplicación en modo texto a un entorno gráfico, y además asegura la independencia del código con respecto al GUI que finalmente se utilice, ya sea Windows 95, Windows NT o incluso OS/2.
Como ya se ha comentado, basta recompilar los actuales programas para migrarlos a un entorno gráfico, obteniendo con ello una auténtica aplicación Windows pero con caracteres en lugar de controles gráficos. Pues bien, utilizando unos elementos propios de Xbase++, denominados XbasePARTS (o XBP), es posible transformar poco a poco toda la interfaz sustituyendo GETs por listas, cambiando menús DOS por menús Windows, o reemplazando teclas de función por botones de comando. Los XbasePARTS no son más que clases que aíslan al programador de los detalles propios de cada sistema operativo a la hora de definir y manejar controles. Conceptualmente, vendrían a ser similares a controles ActiveX, aunque su utilización no entraña complejidad alguna.
Es interesante destacar que Xbase++ permite combinar la sintaxis tradicional de Clipper, basada en comandos SAY, GET, READ, SET KET TO o TBROWSE, con XbasePARTS en una misma pantalla. Esta forma de trabajar, denominada Modo Híbrido, facilita una transición progresiva de las aplicaciones. Se incluyen unas 35 clases XbasePARTS que engloban desde controles simples, como PushButtons, a otros más elaborados, como TBrowse en formato gráfico.
Para crear nuevas ventanas puede utilizarse un diseñador visual de formularios, similar al de otras muchas herramientas de programación. El diseñador permite especificar una base de datos para generar el código fuente del formulario de manera automática. El código generado hace amplio uso de los XbasePARTS, ligando cada campo con el tipo de control que resulta más apropiado.
Xbase++ incorpora además un motor de gráficos, GraphicsEngine, que garantiza una salida por pantalla o impresora independiente del dispositivo para bitmaps, metafiles y gráficos vectoriales 2D. El motor ofrece soporte de otros elementos gráficos básicos, como líneas, círculos, rectángulos y curvas, que pueden escalarse, rotarse y trasladarse fácilmente.
Cuando Xbase++ fue concebido, se estableció que debería producir aplicaciones de 32 bits y aprovechar al máximo las ventajas de este tipo de arquitectura. De ahí que la primera plataforma para la que se desarrolló fuera OS/2, como ya se ha comentado. Las actuales versiones de Xbase++ para Windows 95 y NT 4.0 respetan naturalmente esta premisa de diseño, proporcionando aplicaciones nativas de 32 bits cuyos ejecutables cumplen con el formato de ficheros objeto que cada plataforma específica. Huelga decir, por tanto, que Xbase++ no produce programas aptos para funcionar bajo Windows 3.x ni DOS.
Trabajar en plataformas de 32 bits supone una mejora en el rendimiento de las aplicaciones, gracias sobre todo a una mayor capacidad de acceso a los datos de memoria. La memoria máxima teórica a la que tienen acceso las aplicaciones es de 4,2 GB, mientras que los mecanismos de protección contra fallos de los programas son mucho más robustos. Además, Xbase++ genera código nativo (al estilo de CA-Visual Objects) y no el conocido pseudocompilado de Clipper, con lo que el rendimiento es mucho mayor. Por otro lado, Xbase++ incluye su propio compilador y enlazador de 32 bits, que, además de programas ejecutables, es capaz de generar DLLs.
Otra característica propia de los sistemas operativos de 32 bits es el enhebramiento múltiple (multithreading), es decir, la posibilidad de que una aplicación ejecute hebras o partes de su código en paralelo para llevar a cabo una tarea. Esta característica es sumamente interesante de cara a obtener una ejecución más rápida de las aplicaciones, sobre cuando se trata del acceso a bases de datos. Si bien no es habitual disponer hoy en día de máquinas con más de un procesador, donde el enhebramiento múltiple puede parecer tener más sentido, las ventajas de esta función que ofrece el sistema operativo son evidentes aun cuando se disponga de una sola CPU. Implementar el enhebramiento es, no obstante, una tarea compleja, ya que se precisan sofisticados mecanismos para asegurar la correcta ejecución en paralelo.
Xbase++ no sólo soporta el enhebramiento múltiple desde su primera versión, sino que además encapsula todos los tipos de datos del lenguaje para garantizar la operación asíncrona y concurrente de las aplicaciones. De esta forma, el programador de Xbase++ no debe preocuparse por la complejidad que conlleva poner en práctica esta capacidad del sistema operativo. Las operaciones sobre bases de datos, por ejemplo, pueden realizarse ejecutando varias hebras que actúen en primer o segundo plano, en función de las necesidades de la aplicación. Podría entonces dejar en marcha un proceso de búsqueda complejo o una impresión larga, mientras que el usuario imputa datos en otras tablas. Todos los mecanismos necesarios para manejar el enhebramiento múltiple, como tareas de sincronización entre hebras, son gestionados internamente por las clases de Xbase++.
No hay duda de que uno de los hechos que más preocupa a los actuales desarrolladores de lenguajes Xbase es el futuro de su entorno de programación. Como tampoco puede negarse que el modelo de base de datos DBF, orientado a la manipulación de registros y al uso prácticamente individual de los datos, constituye hoy en día una seria limitación del lenguaje.
Para solventar estas deficiencias, Xbase++ implementa un nuevo modelo para la gestión de datos denominado Database Management Language Broker (DMLB). Su propósito es el de encapsular el modelo de base de datos físico y ofrecer acceso a él mediante sentencias y funciones del lenguaje Xbase++. Lo interesante es que esta nueva forma de concebir el acceso a los datos no se limita a las bases de datos orientadas a registro (como los propios ficheros DBF), sino que además permite la gestión de bases de datos relacionales, como SQL, y de cualquier otro modelo cliente/servidor. En otras palabras, Xbase++ permite seleccionar y utilizar el modelo de base de datos que mejor se ajuste a las necesidades de sus aplicaciones.
Xbase++ accede a las bases de datos mediante DatabaseEngines (DBEs), similares en cuanto a concepto a los clásicos RDD de Clipper, pero muy diferentes en funcionalidad. En particular, la flexibilidad que ofrecen es muy superior; por ejemplo, Xbase++ permite crear un índice NTX sobre el contenido de un fichero SDF y hacer una búsqueda mediante el índice. Además, y a diferencia de los controladores RDD, los DatabaseEngines pueden cargarse y descargarse de memoria mientras la aplicación se ejecuta.
El paquete básico incluye cinco BDEs: DBF, NTXII, CDX (compatible e interoperable con FoxPro 3 y 5), SDF (System Data Format) y DEL (ASCII delimitado). Además, existe un paquete opcional que permite el acceso a varios servidores de base de datos relacionales: Oracle 7, DB2 y SQLAnyware. Muy pronto estará disponible el acceso mediante controladores ODBC 2.0 y la integración con Advantage Database Server como motor de datos.
Por otra parte, aunque la sintaxis para el acceso y manipulación de datos puede seguir utilizándose como hasta ahora venía haciendo, Xbase++ permite la introducción de ciertas mejoras en el código que lo simplifican y mejoran su consistencia. Una de ellas es la posibilidad de ligar campos de cualquier base de datos a controles de la pantalla, de forma que cualquier cambio en la base de datos, ya sea un salto de registro o una modificación del mismo, se refleja automáticamente en los controles sin necesidad de introducir código específico para ello. Para ello, debe usarse DBRegisterClient( ), una de las nuevas funciones que Xbase++ incorpora con respecto al lenguaje Clipper estándar.
Xbase++ tiene previsto evolucionar de forma inmediata. En este sentido, los planes que Alaska, su fabricante, tiene sobre este producto son ciertamente excelentes. Si bien Xbase++ cumple hoy su cometido, no es menos cierto que se trata de la primera versión para Windows NT y 95, y que, en consecuencia, su entorno de desarrollo no está tan evolucionado como el de otras herramientas visuales de desarrollo. Pero no olvidemos que el propósito inicial de Xbase++ no es ser un RAD con un lenguaje propietario, sino el de facilitar la verdadera migración de las aplicaciones Clipper y su evolución futura.
Junto a Xbase++, Alaska ha desarrollado XbToolsIII, un paquete adicional que soporta todas las funciones de la biblioteca CA-Clipper Tools III para que no sea necesario retocar el código en el caso de que se utilicen dichas funciones en los programas Clipper. Asimismo, otros fabricantes de bibliotecas están adaptando las versiones de sus productos para que puedan funcionar con Xbase++, lo que demuestra el prometedor futuro que los fabricantes de utilidades ven en este producto.
Alaska |
Sistemas Xbase para DOS |
Compiladores Xbase para Windows |
|
Longitud de cadenas |
Sin límite |
Limitada |
Limitada |
Longitud de arrays |
Sin límite |
Limitada |
Limitada |
Modelo de objetos |
Sí |
No |
Sí |
Ayuda en línea |
Sí |
No |
Sí |
Vía de migración definida |
Sí |
– |
No |
Aplicaciones de 32 bits |
Sí |
– |
No |
Enhebramiento múltiple |
Sí |
No |
No |
Macros/scripts |
Sí |
No |
No |
Código nativo |
Sí |
No |
Sí |
Controladores de base de datos |
Sí |
Sí |
Sí |
Motor de base de datos abstracto |
Sí |
No |
No |
Protección contra fallos |
Sí |
No |
No |
Hable con un experto
¡Estamos aquí para ayudarte! Ponte en contacto con nosotros y descubre cómo
podemos impulsar tu negocio con nuestras soluciones informáticas.
Hable con un experto
¡Estamos aquí para ayudarte! Ponte en contacto con nosotros y descubre cómo podemos impulsar tu negocio con nuestras soluciones informáticas.
BLOG
Formulario de contacto
"*" señala los campos obligatorios
© ABOX