GpGadGets (GGG)

El objetivo de GpGadGet es crear un sistema muy sencillo (que funciona como componente) para crear aplicaciones que corran tanto en el escritorio como en modo Web.

Llamaré programas de escritorio o Desktop a los programas tradicionales que ejecuta Windows y se visualizan como una ventana en el escritorio de trabajo.

Y llamaré formulario (o form) Web a la “típica” entrada de datos visualizada en el navegador WEB.

Un programa realizado con GGG, puede ser ejecutado en los dos modos y puede incluso interactuar un modo con el otro. Por ejemplo, el usuario Desktop puede ver literalmente las acciones del usuario web, responder a preguntas y mucho más.

La solución es una herramienta que hace la “traducción” automática en tiempo de ejecución del form Desktop a un form Web, y hace que las respuestas del usuario, sean tratadas por el form Desktop.

GGG es indicado para pequeñas aplicaciones Web, con sencillos formularios y controles.

El componente “central” tiene las funciones básicas y genéricas para realizar la traducción, y hay otros componentes “hijos” que identifican y traducen cada clase de los componentes Desktop y manejan específicamente las funciones de peticiones y respuestas.

El “usuario” del componente puede extender el conjunto de componentes “hijos” añadiendo su propia “traducción” para componentes no soportados.

GGG es una herramienta genérica y es independiente del tipo de conexión “winsock”, así que está disponible en varios entornos (Indy, Synapse,…) y es posible usarlo en otras librerías “mayores” como IntraWeb, pudiendo agregar servicios “interactivos” a “antiguas” aplicaciones intraweb.

Los casos de uso de GGG son muchos y tiene varios “modos” de uso.

1- Ejecutar una única ventana Desktop para ser “compartida” por todos los usuarios Web, incluido el usuario local Desktop. Puede ser usado, por ejemplo, para hacer un pequeño sistema Chat, o un sistema contador de votos que quiera “verse” directamente el resultado localmente.

2- Ejecutar diferentes formularios Web para diferentes usuarios, en ventanas locales ocultas. Es en realidad el modo WEB “puro” y puedes hacer aplicaciones WEB, pero usando la misma técnica que para hacerla Desktop. Este uso puede ser muy bueno para programadores noveles o con poca experiencia en programación WEB, o también para programadores más experimentados que solo busquen un sistema sencillo e interactivo desktop/Web para aplicaciones o páginas más complejas).

3- Ejecutar diferentes formularios Web de varios usuarios, que se muestran como formularios Desktop. Así en el WebMaster puede “ver” los cambios efectuados por cada usuario en cada uno de los form usados, e incluso interactuar con el: Chatear, ofrecer ayuda, cerrar la conexión….) En realidad, pueden ser muchos los casos de uso en este modo. Puede pensarse en una “nueva generación” de programas hibridos Web/Desktop, que pueden integrar otros elementos de la librería Gp, como control remoto, escritorio de ayuda, web cam, etc…
El componente puede usar tanto el modo “tradicional” POST Web, como el modo “Ajax” para intercambiar información, aunque por supuesto exige tener activado el JavaScript.

Limitaciones

Por supuesto, GGG no es mágico, por lo que no se puede aplicar a todo tipo de aplicaciones Desktop, ya que hay muchos elementos que no tienen “traducción” y otros aun no están “adaptados” por el momento.

Para los componentes no “soportados” es posible tratarlos como una imagen, para ver el elemento como si fuera un elemento grafico más, y responder a un clic (por ejemplo)

De momento no tiene soporte para aplicaciones MDI ni para cajas de dialogo del sistema.

Por otro lado, no todo tipo de servicios Web pueden tener una solución Desktop, por lo que no se puede hacer cualquier programa WEB, aunque puede usar plantillas externas para generar la página Html y así utilizar otros elementos, o puede usarse como un elemento más dentro de una WEB más compleja. También es posible “interceptar” las acciones o comandos para especificar respuestas en Web que no son relevantes en modo Desktop y viceversa.

Por el momento, no es posible usar el modo “interactivo” Desktop/WEB en una librería ASAPI DLL (aunque sí se puede usar formularios “ocultos”), porque un servicio ISAPI no tiene acceso al escritorio (Al menos no hay ninguna forma documentada por Microsoft).

La solución más parecida es un programa ISAPI que actúe como “puente” para llamar a otro servicio “interactivo” ejecutando GGG que si que tenga acceso al escritorio y procese las peticiones devolviendo las respuestas al “puente”. De hecho tengo algún prototipo desarrollado, pero hasta el momento no me urge desarrollarlo más, a la espera de ver como evolucionan otros elementos.

Ejemplos

Ejemplo 1: Convert it

He tomado una “unit” de los programas “demo” que acompaña a las versiones delphi tradicionales. Simplemente he incluido TGpGadGet (el componente motor de la traducción) y TGpSocket que hace el servicio de comunicaciones como servidor http. Asigno el puerto http en 82 y en el evento oncreate, activo el servidor y abre el navegador WEB donde puedes ver la ejecución del programa.

El resultado, es que puedes ejecutar la aplicación en su forma tradicional, pero además esta compartida en Internet. Así cualquiera puede usar la misma aplicación, aunque claro esta, esto plantea un problema de uso, ya que cada usuario esta “interactuando” con la misma ventana. Seria como si dos usuarios con dos ratones diferentes están usando el mismo ordenador.

Este es un ejemplo muy básico, y el uso ‘real’ puede estar limitado. Sin embargo, refleja claramente la vocación del componente. En un uso más real se hubiera configurado a correr diferentes instancias de la ventana (en modo visible o invisible).
Download the example program in sample1.zip, and run the sample1.exe program, which is very simple and no need any installation or settings.

Sample 2: Voteme

El ejemplo 2 es un pequeño sistema de voto. Es un sencillo formulario con 3 botones y un Input, que refrescan un grafico de tarta, mostrando los resultados del voto. El resultado no es muy fiable en cuanto a que un usuario puede votar varias veces.
a ) Primero, necesitariamos la forma de comprobar el usuario que ha realizado la accion. Esto añade nuevos conceptos: Sesión de usuario, Chequear los parámetros de las llamadas http …

Cuando un usuario contacta con el servidor GpServer, se genera una sesión de usuario para recordar alguna información acerca del usuario. Cada sesión de usuario tiene una clave que identifica esta sesión, y es recordada y enviada al servidor como un parámetro más del comando http, o a través de los cookies.

Gp cuenta con la clase componente TResponRequest que es el contexto de la llamada y respuesta de nuestro servidor WEB. Cuando un evento WEB es generado, este se “trasforma” en un evento de nuestra ventada de escritorio. Los típicos eventos de los controles delphi son de tipo TNotifyEvent, que reciben como parámetro (sender:TObject)

Normalmente sender, hace referencia al objeto que produjo el evento. Por ejemplo en el caso del clic en un botón, el objeto que lo produce en el escritorio, es el propio botón, sin embargo, cuando el evento se genere desde la página Web, el objeto sender será el objeto TResponRequest asociado a la petición y respuesta a esta llamada.

El programador puede saber muchas cosas consultando este objeto, por ejemplo la sesión de usuario que produce esta llamada.
b ) El ejemplo también ilustra el uso de componentes “personalizados”. El componente TChar, no está soportado por la librería, pero hacemos que fácilmente sea adaptado al formato WEB.
c ) tambien usa una pequeña plantilla que personaliza el resultado.

Sample 3: Firstfact
Es un ejemplo que demuestra el uso de GGG con controles DbStandart.
El ejemplo corre en modo no interactivo, así, cada sesión de usuario WEB tiene su propio formulario, independiente del formulario del usuario Desktop.