PowerBuilder vs. Delphi

      // cambiar el color.
      EditValor.Font.Color = "if( IntToStr(ObtenerSaldoGlobal()) > 0,
                                  clBack,
                                  clRed)"
      // cambiar el texto
      BotonCalcular.Text = "if( IntToStr(ObtenerSaldoGlobal()) > 0,
                                '&Calcular',
                                '&Calculo imposible')"
      // desactivar si procede
      BotonCalcular.Enabled = "IntToStr(ObtenerSaldoGlobal()) > 0"

ObtenerSaldoGlobal es una función escrita en PowerScript que hace una consulta SELECT a base de datos y obtiene un número.
if e IntToStr son funciones internas de Datawindow.

NOTA: He utilizado una mezcla entre Pascal y PowerScript para que los Pascaleros entiendan bien el código.

Como podemos ver, esto es una gran ventaja, que nos hace olvidarnos qué mensaje nos enviará Windows cada vez que cambie la posición de un componente, o cualquier otro cambio en cascada. Además podemos construir listados todo lo complejos que se nos ocurra, simplemente introduciendo campos calculados que llamen a funciones con acceso a base de datos. Esto ahorra mucho tiempo, incluso diría que hay tareas que sólo son posibles a través de este sistema. De hecho, yo todavía no estoy seguro cómo plantearía en Delphi problemas como este.

Otra de las características de la Datawindow, es que cada uno de objetos contenidos dentro de ella (etiquetas, cuadros combinados, listas, campos, botones de radio, botones de chequeo, etc.), tiene su propias reglas de validación, aplicando para esto otra expresión de DataWindow (que como ya hemos visto, nos permitirá tanto funciones internas o externas).

Estos objetos, tienen la capacidad de ser recolocados y modificados por el usuario final, pudiendo así crearse sus propios listados a partir de los que nosotros programemos. Y sólo poniendo a true una de las propiedades del objeto.

También permite que el usuario final guarde una Datawindow a disco (en un formato propietario con extensión PSR), pudiendo consultarla en otro momento. En general: que con dos propiedades ya tenemos hecho un editor de listados, para que los usuarios ajusten los informes, gráficos o incluso mantenimientos, a sus necesidades.

Es posible definir un filtro en el cliente (como la propiedad Filter de los Datasets de Delphi) utilizando expresiones de Datawindow, y un orden en el cliente, que también puede hacerse a través de estas expresiones o simplemente indicando los campos de ordenación.

También cuenta con un buen número de eventos en los que se puede codificar en PowerScript aquello que no podamos hacer a través de funciones internas.

El objeto Datawindow, incluye una consulta SQL a partir de la que tomará los datos (si así lo queremos, o bien utilizar datos definidos en diseño).

El SQL utilizado es un dialecto portable, que la gente de PowerSoft llamó en su día PBSQL. La sentencia SQL se podrá escribir en modo texto (escribiendo nosotros mismos con la sintaxis adecuada) o bien dibujar en modo gráfico con una herramienta especial, pudiendo pasarse de un modo a otro en cualquier momento. El dialecto SQL, se utiliza internamente para permitir que una consulta SQL se adapte a las peculiaridades de las distintas bases de datos. No es que tengamos que limitarnos al ANSI-SQL, sino que a partir de la sentencia que nosotros escribamos (o dibujemos), el entorno la traducirá internamente a un SQL neutro (el PBSQL), y luego, dependiendo de la base de datos donde se esté ejecutando dicha consulta, la volverá a traducir a la sintaxis requerida por la base de datos destino. Esta característica funciona realmente bien... he visto con mis propios ojos como la migración de Oracle a SQLServer de una aplicación bastante grande se hacía en ¡¡1 día!! simplemente corrigiendo pequeños errores con los formatos de fecha.

Creo que Delphi no puede presumir de esto. Si nos limitásemos a utilizar el ANSI-SQL en los TQuery, no podríamos aprovecharnos de muchas características que todas las bases de datos implementan, aunque cada una a su modo. Eso sin contar que utilicemos componentes ADO (pensados para SQLServer/Access), o IBX (para Interbase), o Zeos (para MySQL), o los NCOCI8 (para Oracle), o DBExpress, o quien sabe que saldrá mañana.

Las Datawindows también permiten anidamiento, es decir, dentro de una Datawindow, meto otra, y dentro de esa, otra, y otra, y otra, y... ¡¡Catapún!!... hasta que salte un "Access Violation" (que suele ocurrir cuando nos pasamos de listos). Es algo así como una mezcla de los TFrame (a partir de Delphi 5) y los CompositeReport (del QuickReport), que utilizado con moderación (y cabeza) nos permitirá hacer ese listado que no hay por donde cojerlo (y que tanto les gusta a los jefes).

Desde la versión 6 se incluye un plug-in para Internet Explorer y "Nescafé" Navigator que permite la visualización de Datawindows dentro del navegador. Esta característica abre más aún el abanico de posibilidades, ya que podremos portar fácilmente un aplicación de escritorio, a aplicación web, ya que el 90% de los objetos de una aplicación son datawindows y estos están soportados por el navegador. Además, las posibilidades de representación dentro de un navegador se amplían, ya que no hay que limitarse a lo que el HTML es capaz de hacer, o intentar hacer con ActiveX lo que no conseguimos con HTML. Esta tecnología no es muy recomendable para internet, ya que muy poca gente tendrá instalado el plug-in de Datawindows, y la verdad es que la descarga es bastante “gorda” (unos 3 megas). Sí que puede ser un buen entorno para su utilización una intranet, en la que nos aseguramos que todos los equipos cumplen unas características mínimas, y el ancho de banda es lo suficientemente ancho para no tener problemas.

Delphi soluciona esta faceta utilizando las ActiveForms, que no son más que componentes ActiveX para visualizar desde el navegador. Para estos no es necesario ningún plug-in especial, sino que un navegador que soporte ActiveX será suficiente.

A todo esto que hemos mencionado, hay que agregarle los distintos servicios que nos ofrece la librería de clases PFC, como un servicio de filtrado, de ordenación de registros, grabación de datos, impresión, sincronización de maestros-detalles, de previsualización de listados y un largo etc. Estos servicios, al residir en objetos distintos, sólo estarán en memoria mientras el servicio esté activo, por lo que se reduce la carga de la Datawindow. Más tarde hablaremos del PFC y su arquitectura basada en servicios.

En contra del objeto Datawindow hay que decir que mezcla demasiado todo: el interfaz gráfico, la consulta SQL, las reglas de negocio y el comportamiento a través de sus funciones internas. El resultado final es un objeto "monstruoso" que tiene que ser gestionado a través de una única DLL de la máquina virtual. Esta DLL ocupa más de un mega. ¡¡Un componente que ocupa un mega!! En realidad este código se carga una vez y se reutiliza desde todas las Datawindows de la aplicación (cientos y cientos), pero la carga inicial es bastante lenta. Esto se ha intentado mejorar a través de la arquitectura basasa en servicios, aunque no se ha conseguido un objeto lo suficientemente “ligero”.

Al estar tan ligado el aspecto gráfico con el funcionamiento interno nos encontramos con bastantes problemas, y uno de los más habituales es que nos suele aparecer la misma consulta SQL repartida por varias Datawindows. Esto se soluciona en parte con un objeto Query (que hace las veces del TQuery de Delphi, encapsulando solamente la consulta SELECT) del cual podrán hacer uso en distintas Datawindows, aunque la solución es bastante rústica y deja mucho que desear.

Otro problema al que se están enfrentando, es la separación de las aplicaciones en capas, ya que en los últimos años está proliferando mucho la arquitectura distribuida en 3 niveles. Esto requiere se que separe la interfaz gráfica (capa de interfaz o cliente), las reglas de negocio (capa intermedia, de negocio o servidor de aplicaciones) y los datos (capa servidora o servidor de datos). La Datawindow tiene graves problemas en este aspecto, ya que desde un principio se diseño como un objeto "monolítico", intentando integrar todo dentro de ella (y vemos que la tendencia es justo lo contrario). Quizá por este motivo, la filosofía que están aplicando a DPB se considera bastante forzada, en la que "con calzador" tienen que conseguir que un objeto "que sabe hacer de todo" derive sus responsabilidades a otros objetos, incluso remotos.El intento que hacen se basa en dos herramientas llamadas PowerDynamo (un servidor web) y Jaguar CTS (algo así como el VisiBroker de Delphi), que ambas forman la capa intermedia, a través de un producto llamado EAServer (Enterprise Application Server). Es decir, PowerBuilder y su Datawindow no son capaces de crear arquitecturas en 3 capas y han creado herramientas y aplicaciones adicionales para este tipo de proyectos.

SQL dentro de las tripas.

Otra de las capacidades que nos proporciona PowerBuilder, es la de soportar SQL incrustado dentro del código, sin necesidad de componentes adicionales, sino que el propio PowerScript reconoce tanto SQL estático (con todos los datos conocidos en tiempo de compilación) como dinámico (construido en tiempo de ejecución a partir, por ejemplo, de una variable string).

Dentro de una función podemos realizar un SELECT y retornar el resultado en una variable, comprobar si cierto registro existe, recuperar la descripción asociada a un código o cualquier cosa. Esto es muy cómodo, ya que nos permite realizar consultas sencillas sin tener que insertar (o crear en tiempo de ejecución) componentes adicionales.

También es posible ejecutar consultas a partir de una cadena de texto, ya sea completamente o parcialmente dinámicas. Es decir, podemos tener una cadena con la sentencia a ejecutar, o bien, una cadena con el objeto, con las columnas, etc.

Instrucción parcialmente dinámica (“tabla” es una variable string que contiene el nombre de una tabla):

      SELECT *
      FROM   :tabla;

Intrucción completamente dinámica (“sentencia” es una variable string que contiene la sentencia):

    sentencia = "DELETE FROM FACTURAS"
    EXECUTE :sentencia;

Una de las utilidades de esto es, en vez de incrustar la sentencia directamente en el código, podemos almacenarla en una cadena (que leemos de fichero, o de la propia base de datos) y después ejecutar esta sentencia. De este modo se independiza más el programa de la base de datos, ya que un cambio en el esquema no requeriría una nueva compilación.

Desde mi punto de vista, el SQL incrustado es bastante útil y cómodo, aunque también tengo que decir que los lenguajes modernos huyen de esta técnica, ya que ata demasiado la aplicación a la base de datos (algo similar es el Pro*C de Oracle, que es una tecnología que ya tiene sus añitos y empieza a estar en desuso).

Tuberías...

Otra objeto disponible es el Pipeline, que representa una “tubería” de datos entre una base de datos y otra, pudiendo ser estas de cualquier tipo dentro de los soportados por PowerBuilder. Es muy útil para hacer migraciones de bases de datos, ya que, simplemente indicando el origen y el destino, el proceso nos hará la copia de todos los objetos y datos (o aquellos que seleccionemos), ajustando aquellas sentencias que no sean compatibles en la base de datos destino.

Los objetos de usuario.

PowerBuilder permite también la creación de objetos de usuario, un concepto muy extenso que va desde los Frame de Delphi a las clases de cualquier lenguaje OO.

Básicamente, se pueden crear objetos de usuario de los siguientes tipos:

Visuales
Un panel donde se insertan componentes y se programan sus eventos. Es el equivalente al TFrame de Delphi, aunque disponible desde la versión 1 de PowerBuilder, allá cuando muchos, el único ratón que conocíamos tenía cola y comía queso.

Standard
Objetos heredados a partir de los componentes standard que vienen incluidos con PowerBuilder, tanto objetos visuales (CommandButton, Picture, TreeView, Datawindow ) como no visuales (Transaction, Pipeline, Message, Error, etc.).

Basados en DLL
Se importan todas las funciones de una DLL para construir un componente visual, mapeando mensajes de Windows como métodos (por ejemplo, para acceder a los componentes que residen en la librería ComCtl32.dll).

C++
Crea un envoltorio (wrapper) para acceder a las funciones de una DLL escrita en C++. Hasta la versión 6, PowerBuilder se distribuye con el compilador Watcom C++ y permite crear clases en C++ que luego pueden ser accedidas a través de estos objetos escritos en PowerScript. Esta característica desapareció en la versión 7, pero tienen previsto reintroducirla (con muy buen criterio) en la próxima versión 9, para la programación de componentes nativos en C++.

No visuales (llamados NVO - No Visual Object)
Son el equivalente a las clases de cualquier lenguaje OO, aunque su programación es mucho más visual, ya que cuenta con opciones de menú para crear eventos, métodos, atributos, constructores, etc., en vez de tener que escribirlo todo “a pelo”, conociendo la sintaxis correcta.

Distribuidos (o Shared Objects)
Objetos que residen en la capa intermedia (o de negocio) dentro de aplicaciones multi-capa. La peculiaridad de estos objetos es que funcionan en modo multi-hilo, siendo a través de estos objetos la única manera de crear hilos adicionales dentro de una aplicación PowerBuilder.

¿Y donde se almacena todo esto?

Todos los objetos, ventanas, componentes y código en PowerBuilder, se almacenan en librerías con extensión PBL que contienen tanto el código fuente, como la versión compilada. Esto provoca más de un quebradero de cabeza, ya que cuando el código compilado se corrompe, también perdemos nuestro código fuente. Esto en versiones antiguas era bastante habitual, y aunque cada vez funciona mejor, siempre existe ese riesgo.

Existe un proceso de exportación que nos extrae un objeto concreto de la librería y lo almacena en un archivo de texto, algo así como el archivo .pas de Delphi. Este archivo podemos modificarlo, y volver a importarlo para la compilación, pero esto es una tarea bastante pesada y perdemos las ventajas que nos ofrece el entorno de desarrollo.

PFC: PowerBuilder Foundation Classes.

La librería PFC se compone de un conjunto de objetos de propósito general (je, je, no se lo creen ni ellos) que nos permiten hacer las tareas más habituales de dos ratonazos.

No se puede decir que el PFC sea el equivalente a la VCL de Delphi, ya que este último se trata de una librería de componentes visuales (Botones, Listas, etc.) y en PowerBuilder estos vienen “de fábrica” y son inamovibles.

Los objetos incluidos en el PFC son de más alto nivel y se basan en los componentes visuales para construir interfaces (ventanas de opciones, de listados, mantenimientos maestro-detalle a N niveles, opciones de impresión, etc.), objetos auxiliares (pilas, colas, algoritmos de ordenación, parsers de SQL, soporte para multi-idioma, etc.), componentes compuestos (calculadoras, calendarios, barras de progreso...) u otro tipo de objetos (hasta un total de unos 300 objetos listos para ser utilizados).

La principal característica que introduce es un nuevo concepto de programación: la arquitectura basada en servicios. Es una técnica de diseño para programación orientada a objetos y se basa en que cada objeto tendrá disponibles distintos servicios que pueden ser activados en un momento dado para proporcionar una funcionalidad concreta.

Pongamos un ejemplo para analizar: necesitamos un objeto reutilizable que presente un árbol jerárquico. Este árbol, además debe:

Recuperar y almacenar los elementos en una tabla de base de datos.

Permitir imprimir los datos en modo gráfico, ya sea en color o blanco y negro.

Permitir enviar correo electrónico con un archivo adjunto indicando los datos del árbol.

Soportar Drag & Drop para añadir y eliminar nodos.

Un primer diseño de la clase que haga esto podría ser crear una nueva clase heredada de TTreeview en la que iremos añadiendo los métodos para cada una de las acciones requeridas (LeerBD, GrabarBD, Imprimir, EnviarMail, AceptarDrop y IniciarDrag), además de algunos métodos para configurar estas acciones (ConectarBD, DesconectarBD, ConfigurarBD, ConfigurarImpresion, AniadirAdjuntoMail, ConfigurarMail, y ConfigurarDragDrop). Como podemos ver, la clase ya está creciendo considerablemente, y se puede apreciar como las funciones se pueden dividir en cuatro grupos, según las requisitos pedidos: Base de datos, Impresión, Correo y Arrastre.

En notación UML podríamos representar esta clase según aparece en la Figura 1.

Sin embargo la arquitectura basada en servicios ofrece otra solución muy distinta: se separan las distintas funcionalidades en clases distintas (llamadas Servicios), teniendo como atributo la clase “madre” en cada uno de los servicios. Estos servicios se crearán sólo cuando se requiera la funcionalidad, y no estarán continuamente en memoria.

El diagrama en UML podemos verlo en la Figura 2: el objeto Treeview (de la clase TTreeview) puede activar su servicio de base de datos para leer/grabar datos a una base de datos (activar el servicio sería crear un objeto de la clase TTreeviewSrvBD a través de la función ActivarSrvBD), el servicio de impresión, para imprimir su contenido (crear un objeto de la clase TTreeviewSrvPrint llamando a la función ActivarSrvPrint), el servicio de envío por correo electrónico de sus datos (TTreeviewSrvMail con la función ActivarSrvMail) o bien el servicio de “arrastrar y soltar” (TTreeviewSrvDragDrop a través del a función ActivarSrvDragDrop).

Figura 1