La principal arma de que dispone PowerBuilder es un objeto, llamado DataWindow, que se encarga de realizar todas las operaciones de acceso a base de datos.
La DataWindow es un objeto que encapsula una sentencia SQL, un conjunto de resultados y reglas de negocio en el cliente y una interfaz gráfica para representar todo esto, ya sea en forma de rejilla, como formulario, un gráfico, etiquetas, listado para imprimir, árbol jerárquico, o cualquier otro formato.
Algo así como si juntamos un TQuery, un TDataSource, un TCtrlGrid, un QuickReport, un TTreeView y un TeeChar, todo junto en un mismo componente.
El objeto DataWindow es la piedra angular de PowerBuilder, todo gira en torno a este objeto, cualquier ventana contendrá una o varias DataWindows en la que mostraremos datos, ya sean a partir de una sentencia SQL, datos estáticos (definidos en tiempo de compilación), o bien a partir de un array en memoria.
Con una Datawindow, se pueden hacer tanto ventanas de mantenimiento, como de opciones, listados, gráficos, árboles jerárquicos, listados de etiquetas, componentes avanzados (¡he visto hasta una calculadora hecha con una Datawindow!) y cualquier objeto que se nos ocurra. Me atrevería a decir que se puede hacer una aplicación completa, con el nivel de complejidad que se quiera, sólo con Datawindows y ventanas para mostrarlas.
Esto facilita bastante la programación, sobretodo en proyectos grandes, en los que toda la programación es muy homogénea (siempre se utiliza el mismo componente y 4 ó 5 más, así que no hay dudas de qué utilizar).
Pero claro, saber utilizar bien el objeto Datawindow no es fácil.
Cuenta con un conjunto muy extenso de métodos (para hacer todo lo que hace, es normal que necesite muchos), una lista bastante larga de eventos, otro conjunto de funciones internas para los campos calculados (más o menos unas 10 veces las que ofrece QuickReport), y un sistema de atributos dinámicos que quita el hipo "al más pintao".
El conjunto de funciones internas incluye las funciones típicas (max, min, avg, sum, if, etc.), incluso cualquier función normal escrita en PowerScript se puede utilizar como si fuera una función interna. Es decir, podemos escribir nuestras propias funciones normales, y utilizarlas desde los campos calculados, desde un evento, o desde cualquier lugar del programa. Un uso típico a esto suele ser escribir una función que acceda a base de datos para obtener un dato (por ejemplo un saldo, o un total de una tabla) y utilizar esta función dentro de nuestros listados. Muy útil para listados muy enrevesados, que tienen forma de cualquier cosa menos de listado.
El conjunto de funciones internas incluye las funciones típicas (max, min, avg, sum, if, etc.), incluso cualquier función normal escrita en PowerScript se puede utilizar como si fuera una función interna. Es decir, podemos escribir nuestras propias funciones normales, y utilizarlas desde los campos calculados, desde un evento, o desde cualquier lugar del programa. Un uso típico a esto suele ser escribir una función que acceda a base de datos para obtener un dato (por ejemplo un saldo, o un total de una tabla) y utilizar esta función dentro de nuestros listados. Muy útil para listados muy enrevesados, que tienen forma de cualquier cosa menos de listado.
Imaginemos que queremos que un botón (Button1) se sitúe 50 pixels por debajo de una etiqueta (Label1). En PowerBuilder podríamos asignar a la propiedad "Top" el valor:
Button1.Top = "Label1.top + Label1.height + 50"
Y esta expresión se irá recalculando dinámicamente, cada vez que sea necesario. De este modo, cada vez que la posición de Label1 cambia, la posición del botón también, independientemente del origen del primer cambio (ya sea por programa, por cambio de la resolución de pantalla, o porque a su vez es otra expresión calculada dinámicamente). Incluso se pueden incluir cualquier función interna, o nuestras funciones dentro de estas expresiones.
Si ahora, lo que queremos es que el color del texto de un Edit aparezca en rojo si el saldo global es negativo, y que el texto de un botón cambie de "Calcular" a "Cálculo imposible", y además, dicho botón se desactive, codificaremos del siguiente modo:
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.
