byte – suplemento especial 71: guía de borland para linux ...• aplicaciones de escritorio. •...

Byte – Suplemento especial 71:

Guía de Borland para Linux: KYLIX

Por Danyserv – Grupo Danysoft

marzo de 2001 - (902) 123146 www.danysoft.com

58

Artículo creado por el equipo Danysoft, (2001) todos los derechos reservados. Para cualquier consulta sobre el

mismo contacten con [email protected] - www.danysoft.com

58



Índice Introducción

Aspectos tecnológicos más destacados La estructura del libro Para seguir los ejemplos del libro... Parte I. Cómo aprovechar las novedades de Borland Kylix Compatibilidad Windows / Linux Compatibilidad Delphi / Kylix

Características perdidas en Kylix Puntos a la hora de revisar código antiguo

Desarrollo visual Arquitectura de la CLX

Soporte para Apache dbExpress

dbExpress vs BDE Características de un driver de bases de datos Clases principales de dbExpress Mapeo de tipos de datos

MyBase: Motor de bases de datos personal basado en XML Conclusiones

Parte II. Aplicaciones de bases de datos con Kylix

Un poco de historia Me “caching” los datos Kylix & MIDAS Conjuntos de datos grandes Concurrencia Relaciones maestro / detalle Actualizaciones personalizadas Conclusiones Parte III. Desarrollo Web con Kylix Edición Server Aplicaciones Web Kylix El Servidor Web Apache Creando una aplicación CGI para un Servidor Web Apache Tour por WebBroker

La clase TWebDispatcher El WebModule La clase TWebActionItem La clase TWebRequest La clase TWebResponse La clase TCustomContentProducer

Creando aplicaciones CGI para Apache utilizando DBExpress

58



Procesos Apache Módulos DSO Apache. Creando módulos DSO con Kylix Kylix y XML Kylix y WAP Conclusiones Parte IV. Cómo ve el mercado a Borland Kylix Primeros pasos muy prometedores.

Apéndice A: Configuración del Sistema utilizada para los ejemplos prácticos

En este apéndice le indicamos el software que fue utilizado cuando se desarrollaban los ejemplos para la Web incluidos en este documento.

Apéndice B: Enlaces interesantes

En este apéndice le indicamos webs útiles relacionadas con Kylix y Apache. Apéndice C. Folleto de características Folleto de características técnicas de Borland Kylix.

58



Introducción.

Kylix es una herramienta de desarrollo rápido de aplicaciones (RAD por Rapid Application Development) nativas Linux de alto rendimiento que acelera y simplifica radicalmente a través de la programación visual basada en componentes. Kylix está pensado para el desarrollo de:

• Aplicaciones de escritorio. • Aplicaciones para Internet. • Aplicaciones de bases de datos cliente/servidor. • Aplicaciones distribuidas de n-capas.

Kylix posee un compilador que genera código nativo Linux en la forma de ejecutables o de objetos compartidos (Shared Objects, el equivalente Linux a las DLLs de Windows) en formato ELF. Presenta un entorno de desarrollo visual del tipo “two-way”, es decir, los cambios realizados en la parte visual se ven reflejados en el código fuente y viceversa. Kylix también introduce una nueva biblioteca de componentes llamada CLX que permite el desarrollo de aplicaciones multi-plataforma. Si bien el proyecto Kylix es Delphi y C++Builder para Linux este primer lanzamiento sólo incluirá Delphi para Linux. Hay tres versiones disponibles: Server, Desktop y Estándar. Haciendo una comparación entre Linux y Windows, como lo muestra el siguiente gráfico, podemos ver que las diferencias, desde el punto de vista del programador de aplicaciones, son mínimas.

Tanto en Linux como en Windows el programador de aplicaciones utiliza un entorno integrado de desarrollo (IDE por Integrated Development Environment) idénticos. Tanto Kylix como Delphi poseen un compilador de código nativo que genera aplicaciones nativas para sus respectivas plataformas.

58



El desarrollo en Kylix está basado en la CLX, la nueva biblioteca de componentes multi-plataforma. El desarrollo en Delphi está basado en la VCL, aunque Delphi 6 también incluirá la CLX. La manera en que la CLX se las arregla con el núcleo de Linux no es un problema que deba resolver el programador de aplicaciones, así como la manera en que la VCL se las arregla con Windows tampoco. A pesar de que en este punto hay diferencias importantes, estas diferencias son ocultadas por la CLX en Linux y por la VCL en Windows de manera tal que el programador de aplicaciones ni siquiera se entere de ellas. Estas son muy buenas noticias para el programador de aplicaciones. Aspectos tecnológicos más destacados Kylix introduce una nueva capa de acceso a datos multi-plataforma llamada dbExpress. El DBE seguirá existiendo pero los planes de Borland son reemplazarla por el dbExpress. Esta nueva capa es mucho más delgada que su antecesora y hasta el momento posee drivers nativos para acceder a MySQL, InterBase, Oracle y DB2. Delphi 6 incluirá el dbExpress. La tecnología MIDAS, presente en Delphi desde la versión 3, juega un papel fundamental en el desarrollo de aplicaciones de bases de datos, ya sean locales, cliente/servidor o distribuidas. En este último tipo de aplicaciones, MIDAS ofrece soporte para SOAP y XML. En lo que respecta a aplicaciones para Internet, Kylix ofrece soporte para Apache, el servidor web más popular de Linux, además de soporte para XML, DHTML y para el desarrollo de aplicaciones que utilicen TCP/IP, sockets, HTTP, FTP, SMTP, POP3, etc. La estructura del libro Para una mayor organización de la exposición, hemos dividido este libro en los siguientes apartados diferenciados: • La primera parte se encarga de comentar en profundidad las novedades que ofrece

Borland Kylix, teniendo en cuenta a los usuarios de Delphi / C++ Builder y como conseguir la máxima compatibilidad entre las plataformas Windows / Linux.

• La segunda parte se centra en uno de los aspectos más importantes para los programadores: “La gestión de bases de datos con Kylix”, estudiando en detalle las características del sucesor del BDE “el DBE” .

• La tercera explica el desarrollo de aplicaciones para Internet desde Kylix, su integración con XML, WAP, y como desarrollar para servidores Apache.

• En la cuarta y para los ansiosos de información, repasamos las novedades que irán enriqueciendo poco a poco las posibilidades de Kylix.

• Finalmente incluimos 3 apéndices en los que le comentamos que software se utilizó en los ejemplos Web. Enlaces interesantes sobre Kylix y Apache. El folleto de las características de Kylix, diferencias entre versiones y dónde adquirirlo.

Para seguir los ejemplos del libro... Los ejemplos que se presentan en el libro están disponibles en la Web de Danysoft Internacional, en la siguiente dirección: http://www.danysoft.com/kylix.htm

58



Parte I. Cómo aprovechar las novedades de Borland Kylix Compatibilidad Windows / Linux Kylix es Delphi y C++Builder para Linux, por lo tanto la compatibilidad, desde el punto de vista del programador de aplicaciones, es casi total. No es así para los programadores de componentes, ya que en este terreno las diferencias son más importantes. Una aplicación desarrollada con Delphi 5 utilizando la VCL puede ser fácilmente migrada a Kylix. La CLX es muy parecida a la VCL. La mayoría de los componentes de la VCL existen en la CLX con el mismo nombre, las mismas propiedades, los mismos métodos y los mismos eventos. Algunos componentes de la VCL directamente no existen en la CLX, como los componentes para COM ya que COM no existe en Linux. En general aquellos componentes de la VCL específicos de Windows no existen en la CLX. También hay componentes nuevos en la CLX, es decir, componentes que no existen en la VCL de Delphi 5. Estos componentes nuevos de la CLX aparecen como resultado de cambios de fondo introducidos en Kylix como son la aparición de dbExpress y el hecho de que los componentes visuales están basados en las bibliotecas QT, un conjunto de bibliotecas escritas en C++ disponibles para Windows y para Linux desarrolladas por la empresa Troll Technologies. (www.trolltech.com). Lo que definitivamente no es compatible son las llamadas a la API de Windows. Una aplicación Delphi 5 que haga llamadas directas a la API de Windows no podrá ser migrada directamente. Si tiene aplicaciones desarrolladas con Delphi 5 que piensa migrar a Linux utilizando Kylix entonces comience a reemplazar las llamadas a la API de Windows por componentes. Esto hará más fácil la migración ya que solo será necesario desarrollar un componente equivalente con Kylix. En lo que respecta a componentes de terceras partes, Borland ha hecho un trabajo importante para asegurarse que los principales proveedores de componentes acompañaran la migración de Delphi a Linux. La mayoría lo ha hecho y ya están disponibles para Kylix los paquetes de componentes más populares del mercado. Sin embargo, si utiliza componentes ActiveX tenga la seguridad de que no estarán disponibles para Kylix, al menos no en la forma de ActiveX ya que Linux no sabe nada acerca de ActiveX. De todas formas, los proveedores de componentes generalmente ofrecen una versión ActiveX para Visual Basic y demás productos, y una versión específica para Delphi y C++Builder. Si planea migrar sus aplicaciones Delphi 5 a Kylix y utiliza componentes de terceras partes póngase ya mismo en contacto con Danysoft para asegurarse una versión de los mismos para Kylix. Si está por comprar componentes nuevos tenga en cuenta que sería mejor que estuvieran disponibles para Kylix también.

58



Compatibilidad Windows / Linux

Hoy en día tenemos Delphi 5 y Kylix. El desarrollo de aplicaciones multi-plataforma utilizando el mismo código fuente aún no es posible. Si tenemos una aplicación desarrollada con Delphi 5 y queremos migrarla a Kylix, el código fuente sufrirá modificaciones, más allá de que estas modificaciones las hagamos nosotros mismos o las haga Kylix o algún utilitario que ande dando vueltas por ahí. El hecho es que el código fuente no es el mismo para Delphi 5 y para Kylix. A partir del lanzamiento de Delphi 6 esto será posible gracias a que Delphi 6 incluirá la CLX.

Aplicaciones multi-plataforma

Con la CLX será posible el desarrollo de aplicaciones multi-plataforma que utilicen el mismo código fuente. Si tenemos una aplicación desarrollada con Delphi 6 podrá ser migrada directamente a Kylix sin sufrir ninguna modificación, eso si, siempre y cuando utilicemos la CLX. Por el momento la CLX permite el desarrollo de aplicaciones para Windows y para Linux, pero algunos no descartan la posibilidad de que en el futuro veamos versiones de Kylix para otras variantes de UNIX. Todo lo que sea desarrollado utilizando la CLX podrá ser migrado de una plataforma a otra utilizando el mismo código fuente sin necesidad de realizar ninguna modificación. Compatibilidad Delphi / Kylix Cuando se habla de compatibilidad entre compiladores para diferentes plataformas, siempre se encontrará que existen diferencias entre un entorno y el otro. Podemos enumerar algunas que el proyecto Kylix tiene con respecto a Delphi, por ejemplo el cambio de nombre de algunas de las units de la VCL como Forms por Qforms,

58



Controls por Qcontrols, etc, lo cual implica que los controles y forms son diferentes entre uno y otro, pero ¿cuáles son las diferencias y como portamos el código?. Antes de contestar esta pregunta tomemos algunos puntos en cuenta:

• Delphi / Kylix se basan en lenguajes orientados a objetos, lo cual implica que se pueden generar clases semejantes (iguales métodos y propiedades) pero con diferentes implementaciones. • La librería visual de Delphi / Kylix esta compuesta de componentes los cuales son objetos y cumplen las características del punto anterior. • Linux no posee la API de Windows. • Linux no posee letras de unidades como C:\, el sistema de ficheros es diferente. • Linux distingue mayúsculas de minúsculas.

Las afirmaciones anteriores conducen a las siguientes conclusiones a la hora de portar código:

• La migración de código no será directa pero Borland afirma que si se cumplieron ciertos requisitos podría llevar menos de un mes. • Dada la filosofía de objetos, los nombres de los componentes serán los mismos en su mayoría salvo excepciones. • La mayoría de las propiedades de dichos componentes serán las mismas, se agregarán nuevas y se perderán otras. • Las clases que no involucren lógica visual (desde TObject a TComponent) serán semejantes entre una y otra implementación.

Por lo tanto la API gráfica será distinta y se perderán los componentes de terceros los cuales deberán migrar a Linux. Esto nos lleva a que aplicaciones que hacen uso intensivo de la API de Windows deberán rescribir código y algunas veces pueden llegar a perder funcionalidad, la cual deberá ser reemplazada por alguna aproximación a la misma en el entorno Linux. Kylix presenta en su entorno una nueva librería gráfica de componentes la cual se llama CLX (se pronuncia clix). La CLX está basada en QT. QT es una API gráfica independiente de la plataforma la cual se puede ejecutar tanto en Linux como en Windows. Esta Librería se incluirá en futuras versiones de Delphi para Windows, con lo cual la migración será aún más transparente ya que el mismo código se podrá ejecutar en Windows y en Linux sin cambios, dado que los componentes serán compatibles al estar basados en QT. Esto no implica que Borland discontinúe la VCL (Visual Component Library) la cual usa la API de Windows, pero en el caso de utilizar esta última se deben tener en cuenta las diferencias que existen con CLX si el código se desea portar a Linux. Otro punto a tener en cuenta es la captura de mensajes de la API de Windows los cuales no existirán en Kylix, aunque si existirá un motor de eventos el cual esta basado en QT. Esto implica que se deberá tratar de reducir los métodos con la directiva “message”, la cual será soportada pero no capturará eventos como un clic del ratón o cualquier evento relacionado con componentes, excepto aquellos mensajes atrapados y reenviados por Kylix con la directiva dispatch de la clase TObject. También aquellos que usen Assembler embebido en código deberán revisar cuidadosamente la documentación de Kylix dado que en Linux la estructura de los programas es diferente a la de Windows. Características perdidas en Kylix

58



Dado que Kylix esta pensado para Linux es lógico pensar que todo lo correspondiente a ActiveX, Automatización OLE, COM/DCOM se perderá en Kylix, así como también el editor de Librería de Tipos (Type Library) y cualquier OCX utilizando. Borland está trabajando con Red Hat y TrollTech en la especificación de componentes para Linux. También se perderá compatibilidad con Windows 3.11, como es lógico (no se migrarán tales componentes). Tampoco se migrará la BDE la cual será reemplazada por el dbExpress, el cual implica un nuevo conjunto de componentes para acceso especializado en SQL. En este punto Borland no informó que pasará con los usuarios de Paradox, aunque en conferencias ha dicho que posiblemente desarrollen alguna herramienta para migrar dichas tablas a Interbase u otro motor de SQL. Este punto es importante ya que aquellos que basaron sus desarrollos en componentes como TTable o TQuery deberán realizar cambios sustanciales al código, no así aquellos que basaron sus desarrollos en TDataSet, lo cual les asegura compatibilidad. Puntos a la hora de revisar código antiguo Aquellos que hayan utilizado nombres de archivos directamente en código sin hacer uso de constantes se verán obligados a revisar sus códigos en detalle para reemplazarlos por constantes. Revisar si existen llamadas directas a Windows como al API gráfico y reemplazarlas por componentes o clases equivalentes (Ejemplo: usar TCanvas en vez de llamar a funciones de dibujo del API de Windows en forma directa). Revisar el uso de mensajes y de cualquier función relacionados con ellos y tratar de reemplazar los mismos con los métodos dinámicos presentes en las clases por medio de herencia o utilizando eventos en el caso de que existan. Revisar el uso de "cast" a clases no implementadas como ser TWinControl, TWinControl(Self) o Self as TWinControl. TWinControl fue cambiada por TWidgetControl por lo tanto las diferencias entre una y otra pueden ser sustanciales, pero en el caso del "cast" puede utilizarse una técnica como la siguiente: Type TWinControl = TWidgetControl; Aunque se deberá tener cuidado con el uso de las propiedades, ya que pueden no existir o funcionar de manera diferente en una clase y en la otra. A pesar de haber cambiado el nombre de esta clase la cual es muy importante, Kylix no cambió los nombres de las clases de los componentes que aparecen en la paleta de componentes, con lo cual se garantiza compatibilidad desde dos puntos bien definidos:

• Compatibilidad de nombres y funcionalidad de clases incluidas en la unit (classes. Pas) o sea desde TObject a TComponent y también TControl. • Componentes que aparecen en la paleta de componentes del IDE.

Por último hablemos de las interfaces. Kylix posee, al igual que Delphi, implementación múltiple de interfaces las cuales heredan de IInterface en vez de IUnknown pero define IUnknown = IInterface también define IDispatch con lo cual se deja una puerta abierta para una futura implementación de comunicación con objetos COM.

58



Ahora bien ¿de qué nos sirven las interfaces en la migración?. Esta pregunta se puede contestar con la definición en si de una interfaz, la cual no es más que una especie de contrato de propiedades y métodos pero no dice nada sobre cómo se deben implementar tales Interfaces, lo cual nos deja la puerta abierta para implementarlas en cualquier entorno o sistema, siempre y cuando se respete el contrato. O sea, que no sería una mala opción orientar nuestro desarrollo a interfaces, con clases que implementen estas interfaces en cada entorno sacando las mejores características de cada sistema operativo. Claro, el trabajo de armar un conjunto de clases que implementen las interfaces sería un trabajo doble, pero todo se basa en un buen diseño de nuestros sistemas y de lo que realmente se quiere lograr. Como conclusión podemos decir que Kylix está muy bien pensado para migrar aplicaciones basadas en la VCL pero se encontrarán en dificultades aquellos que hacen uso intensivo de la API de Windows, los cuales deberán poner en juego mas horas de programación y estudio para lograr una migración correcta a Linux. También cuando las próximas versiones de Delphi incluyan QT, la migración será directa si se basa en CLX todo el desarrollo. Este último punto se potencia si en el futuro Borland migra Kylix a entornos como SUN u otros UNIX. Desarrollo visual El entorno de desarrollo visual de Kylix es idéntico al de Delphi 5. De hecho Kylix es una herramienta de desarrollo rápido de aplicaciones (RAD por Rapid Application Development) basado en componentes, como lo es Delphi 5.

El entorno de desarrollo presenta, en la parte superior el formulario principal de Delphi en dónde lo más destacado es la paleta de componentes, con más de 165

58



componentes listos para usar agrupados por funcionalidad para facilitar su localización. A la derecha es posible ver el Inspector de Objetos que permite acceder a las propiedades y a los eventos de los objetos seleccionados. El Inspector de Objetos simplifica el proceso de desarrollo al permitir acceder de manera visual a las propiedades de los objetos y establecer, en tiempo de diseño, valores de propiedades complejas por medio de listas y editores de propiedades. El Editor de Código permite tener control total sobre el código fuente de nuestros proyectos. Ofrece características de edición avanzadas, como por ejemplo, con una simple combinación de teclas es posible saltar de la declaración de un método a su implementación, acceder a declaraciones en otras unidades, escribir menos y con menos errores gracias al asistente para la escritura de código que muestra los parámetros de procedimientos y funciones y las propiedades y métodos de los objetos, además de todas las funciones propias de la edición de código como copiar, pegar y mover líneas, bloques o caracteres, deshacer, buscar y remplazar, etc. Algo para destacar es la posibilidad de configurar las teclas rápidas de acuerdo a los editores de código más populares. También es posible configurar los colores, tipos de letra y demás opciones para destacar palabras reservadas, texto, etc. El Explorador de Código permite localizar rápidamente una línea de código específica. Por defecto aparece integrado a la ventana del Editor de Código y muestra las declaraciones de clases, procedimientos y funciones, variables y constantes, unidades en la cláusula uses, etc. de la unidad seleccionada en el Editor de Código. El Diseñador de Formularios permite diseñar los formularios de nuestra aplicación de manera 100% visual. Sólo hay que seleccionar un componente de la paleta de componentes y colocarlo en el formulario en el lugar deseado. Luego por medio del Inspector de Objetos podemos acceder a sus propiedades y métodos, y todos los cambios realizados se verán reflejados en el Editor de Código. El Administrador de Proyectos permite un control total sobre los archivos de un proyecto a la vez que nos permite trabajar con varios proyectos simultáneamente. Arquitectura de la CLX La CLX (los americanos la llaman clix) es la nueva biblioteca de componentes multi-plataforma. Es importante aclarar que la CLX no es sólo la biblioteca de componentes para Linux como muchos piensan. Es decir, no es sólo una versión de la VCL para Linux. La CLX es mucho más que eso. Forma parte de Kylix y formará parte de Delphi 6 y, gracias a la CLX, combinando ambos productos será posible el desarrollo de aplicaciones multi-plataforma que utilicen el mismo código fuente. La CLX está dividida en 4 partes: BaseCLX, VisualCLX, DataCLX y NetCLX.

BaseCLX es el corazón de las aplicaciones multi-plataforma. Posee rutinas, clases y tipos base similares a los existentes en las actuales unidades System, SysUtils, etc. DataCLX contiene los componentes de acceso a datos del lado del cliente, tales como ClientDataSet, DataSource y SQLConnection. Los componentes de DataCLX pueden

58



ser utilizados para aplicaciones de bases de datos locales, cliente/servidor y distribuidas de n-capas. dbExpress es la capa de acceso a datos multi-plataforma (también será parte de Delphi 6) que contiene los componentes de acceso a datos del lado del servidor que proveen datos a los componentes DataCLX.

El programador de aplicaciones verá un cambio importante a la hora de desarrollar aplicaciones de bases de datos ya que Kylix está totalmente basado en MIDAS para este tipo de aplicaciones. La nueva capa de acceso a datos multi-plataforma, llamada dbExpress, no soporta “caching” de datos. Esta tarea está delegada en el componente ClientDataSet que soporta “caching” de datos desde su aparición en Delphi 3. La gran ventaja de este cambio es que dbExpress es mucho más liviano que su antecesor (el DBE) y mucho más rápido. Además, el programador gana control en las gestión local de datos ya que todo pasa del lado de la aplicación y no queda nada al respecto del lado de la capa de acceso a datos como ocurre con el BDE. dbExpress se limita a la comunicación con la base de datos. La actualización de datos es resuelta por la clase SQLResolver como ocurre en aplicaciones MIDAS actuales. Esta clase está incluida en el componente DataSetProvider. dbExpress está basado en interfaces similares a las de JDBC u ODBC. Las principales interfaces son SQLDriver, SQLConnection, SQLCommand, SQLCursor y SQLMetaData. De esta manera es más simple escribir drivers de bases de datos para dbExpress o actualizar los existentes. Para trabajar con dbExpress, DataCLX ofrece un conjunto nuevo de componentes. Los principales son:

• SQLDataSet: descendiente de una nueva clase llama TUniDataSet, permite conectar los nuevos drivers de dbExpress con los componentes “data aware”. • SQLConnection: es similar a los actuales Database y ADOConnection. Permite establecer una conexión con una base de datos a través de dbExpress. • SQLQuery, SQLStoredProc, SQLTable: similares a los actuales Table, Query y StoredProc. Estos componentes facilitan la migración de aplicaciones de bases de datos a los componentes basados en dbExpress.

NetCLX contiene los componentes relacionados con Internet. Kylix (y Delphi 6) extiende la tecnología WebBroker con soporte para Apache. Con Kylix (y Delphi 6) es posible el desarrollo de aplicaciones para servidores web Apache en la forma de CGI o DSO. NetCLX también incluye soporte para XML y DHTML y componentes

58



para conexiones TCP/IP por sockets y componentes para HTTP, FTP, SMTP, POP3, etc. Soporte para Apache Apache es el servidor web más popular de Internet. Se calcula que el 60% de los servidores web de Internet están montados con Apache. Las principales razones del éxito de Apache son: es estable, es flexible, es código abierto, está disponible para muchas plataformas y es gratis. Apache es un servidor maduro con una herencia similar a la de muchos servidores web comerciales. Está construido de manera modular, lo cual, combinado con el hecho de que es código abierto, permite que tenga ventajas únicas frente a sus competidores comerciales. Apache está disponible para la mayoría de las versiones comerciales y no comerciales de UNIX, incluyendo Linux y ha sido portado a Windows 95/98/NT/2000 y OS/2. La manera de extender la funcionalidad de Apache es por medio de los llamados “módulos de Apache”. Los módulos de Apache ofrecen máximo rendimiento ya que forman parte del mismo servidor web, a diferencia de otras tecnologías, como CGI, que son aplicaciones separadas del servidor web y por ese motivo ofrecen menor rendimiento. Además, los módulos de Apache permiten un mejor acceso a las características internas del servidor web y no requieren que los navegadores web tengan características especiales. Los módulos de Apache son binarios compilados que pueden ser enlazados de manera estática o dinámica con el servidor web. De manera estática significa que Apache puede ser compilado nuevamente incluyendo el módulo generado. Los módulos de Apache pueden ser escritos con C, Perl o Kylix. Los módulos de Apache se conectan con Apache mediante la instalación de manejadores (handlers) para la porción de ejecución del servidor web con la cual el módulo necesita interactuar. El manejador puede decidir si maneja, ignora o aborta el procesamiento de la fase deseada antes de devolverle el control a Apache. La API de Apache permite acceder a prácticamente todo, incluyendo las fases de arranque, inicialización y descarga del servidor web. Sin embargo, en la mayoría de los casos los módulos modifican las fases de requerimiento y respuesta. Apache maneja cada requerimiento HTTP y su correspondiente respuesta en una serie de fases cada una de las cuales puede ser accedida por medio de un módulo. Las fases más importantes son:

• Traducción URI: durante esta fase la URI del requerimiento entrante es generalmente traducida en una ruta a un archivo físico en el servidor web. • Control de Acceso: esta fase averigua de donde viene el requerimiento. • Autenticación: esta fase determina la identidad de quien generó el requerimiento. • Autorización: esta fase determina si quien generó el requerimiento tiene los derechos de acceso necesarios. • Verificación del tipo MIME: durante esta fase se realiza una determinación inicial del tipo de documento MIME. • Respuesta: en esta fase se completa el contenido de la respuesta. Si un módulo se encarga de esta fase, Apache le pasa el control junto con la información necesaria para llevar a cabo la tarea.

58



• Registro: durante esta fase es posible registrar las acciones realizadas durante el ciclo completo utilizando las facilidades de registro de Apache. • Liberación: durante esta fase es posible liberar recursos asignados durante las fases anteriores.

La tecnología WebBroker de Delphi consiste en una serie de componentes, clases y asistentes que trabajan en conjunto para hacer que el desarrollo de módulos web sea simple. WebBroker fue introducido en Delphi 3 con soporte para CGI, WinCGI, ISAPI y NSAPI. Con Kylix, la tecnología WebBroker ha sido expandida para incluir soporte para módulos de Apache. Los principales componentes y objetos de la tecnología WebBroker son:

• PageProducer: permite la generación de páginas HTML dinámicas. Tiene la capacidad de encontrar y reemplazar marcas especiales en archivos HTML. Para cada marca encontrada dispara un evento en el cual es posible reemplazar dichas marcas por contenido dinámico. De esta manera al momento de generar contenido para una respuesta sólo se generan las porciones dinámicas del mismo. • DataSetPageProducer: obtiene datos de un DataSet asociado. Lo que hace este componente es buscar marcas en el archivo HTML asociado que coincidan con el nombre de los campos del DataSet asociado y reemplazar las marcas por el contenido de los campos. Este componente está pensado para generar contenido que muestre un registro por vez. • DataSetTableProducer: obtiene datos de un DataSet asociado y genera una tabla HTML con ellos. Si bien no utiliza ningún archivo HTML para generar su contenido, puede ser combinado fácilmente con archivos HTML externos para generar contenido más elaborado (por ejemplo, que incluya Flash). Posee propiedades que permiten configurar la tabla HTML generada y eventos que permiten personalizar el proceso de generación. • QueryTableProducer: tiene una funcionalidad similar al DataSetTableProducer con la diferencia principal de que el DataSet asociado debe ser un Query. El componente busca en el requerimiento campos que coincidan con los nombres de los parámetros del Query y se encarga de pasarle dichos parámetros y abrirlo para genera su contenido en base a los datos del mismo. • WebModule y WebDispatcher: contienen la lógica necesaria para manejar requerimientos HTTP. Por medio de acciones es posible generar el contenido solicitado. Cada acción tiene una propiedad llamada PathInfo que determina cuando una acción determinada debe tomar el control. Por medio de las acciones es posible que un módulo genere contenidos diferentes. • ApacheRequest y ApacheResponse: representan el requerimiento y la respuesta generada. Por medio de ApacheRequest es posible obtener información del requerimiento. Las características y el contenido de la respuesta son indicados por medio de ApacheResponse.

VisualCLX es la parte visual de la biblioteca de componentes. Está basada en la biblioteca de componentes QT de la empresa Troll Technologies que actualmente está disponible para Windows y para Linux. Gracias a QT, las enormes diferencias existentes entre Windows y Linux en todo lo que tiene que ver con la parte visual de una aplicación son casi completamente eliminadas permitiendo que Kylix tenga un

58



conjunto de componentes visuales casi iguales a los disponibles actualmente para Windows. QT es una biblioteca de clases independientes de la plataforma escritas en C++ y disponibles actualmente para Windows y Linux. Es la biblioteca de clases escritas en C++ más popular de Linux y es utilizada por KDE, uno de los entornos gráficos más utilizados de Linux. En Linux, QT es código abierto para las aplicaciones que son código abierto. Las clases de QT son muy parecidas a las clases de la VCL. Las propiedades aparecen como el par de métodos Get y Set y los eventos como señales. QT incluye muchos controles estándar (llamados Widget) y maneja el bucle de mensajes. QT utiliza XWindow en dónde una Window es un XHandle y un Graphic Context es un XGraphic Handle. El estilo de desarrollo con QT es muy cercano al de Windows y el modelo gráfico de QT es muy parecido al de la VCL. Para más información visitar www.trolltech.com

La jerarquía de clases de la VisualCLX no es muy distinta a la de la VCL. El cambio más importante está dado por la nueva clase TWidgetControl en sustitución de la clase TWinControl de la VCL. El resto, como se puede observar en el gráfico anterior, es prácticamente igual. dbExpress El almacenamiento y acceso a datos juega un rol fundamental en la industria de la tecnología de la información. Es muy difícil una aplicación de negocios que no necesite interactuar con una base de datos y la clave para este tipo de aplicaciones es el rendimiento. En el pasado, estándares como ODBC y JDBC ofrecieron una capa de acceso a bases de datos independiente que permitía acceder a una gran variedad de bases de datos. A través de una interfaz común, características específicas de una base de datos eran dejadas en la oscuridad. Al mismo tiempo tratar de agregar la gran cantidad de

58



características específicas de cada base de datos hacían que la capa de acceso a datos fuera demasiado compleja. dbExpress es una interfaz ampliable, independiente de la base de datos y multi-plataforma que provee un conjunto de métodos para el procesamiento dinámico de SQL. dbExpress constituye la nueva generación de la capa de acceso a datos para Kylix, Delphi y C++Builder. Lo que sigue es una explicación de la interfaz de acceso a datos, en que se diferencia de los estándares actuales y una discusión de los aspectos internos de cómo desarrollar un nuevo driver de acceso a bases de datos. dbExpress vs BDE dbExpress es capaz de procesar consultas (queries) y procedimientos almacenados (stored procedures) como el BDE. El BDE es rico en características y un cliente para nada delgado mientras que dbExpress es más simple, fácil de implementar y se ajusta mejor a las características del modelo de MIDAS basado en el DataSetProvider y en el SQLResolver. Las aplicaciones de uso intensivo de bases de datos deberían utilizar consultas o procedimientos almacenados para obtener los datos. Abrir una tabla por medio del BDE no sólo consume recursos del lado del cliente sino también del lado del servidor. dbExpress elimina el concepto de abrir tablas y es recomendable que los cliente utilicen consultas optimizadas para mejorar el rendimiento de acceso a datos. A diferencia del BDE, dbExpress devuelve solamente conjuntos de datos unidireccionales y por lo tanto no soporta “caching” de datos. El componente ClientDataSet de la tecnología MIDAS puede ser utilizado para “caching” de datos y para navegar, indexar y filtrar conjuntos de datos. El DBE almacena información de “metadata” (estructuras de datos) de manera tal que queden disponibles para futuros requerimientos con el consecuente ahorro de tiempo y mejora de rendimiento. dbExpress no almacena información de “metadata” y la interfaz de acceso a “metadata” en tiempo de diseño es implementada utilizando la interfaz principal de acceso a datos. El rendimiento del BDE cuando accede a bases de datos SQL se ve afectado por la generación interna de la consulta para navegación, el acceso a campos “blob” y la obtención de información de “metadata”. dbExpress ejecuta sólo consultas generadas por el usuario por lo tanto optimiza el acceso a bases de datos al no introducir ningún requerimiento adicional. dbExpress administra internamente un “buffer” de registro o un bloque de “buffers” de registro y provee a los clientes los valores individuales de los campos. Por otro lado, el BDE usa un “buffer” de registro asignado del lado del cliente y esto puede ser causa de errores debido a que el cliente podría utilizar un “buffer” de registro demasiado pequeño o corrupto. Entre otras diferencias con el BDE, dbExpress no maneja ningún concepto de consultas vivas, “cache updates”, soporte para creación de esquemas, procesamiento de consultas heterogéneas, etc. dbExpress sólo soporta las siguiente características existentes actualmente en el BDE:

• La complejidad asociada a la configuración del BDE, su distribución y la adaptación de nuevas fuentes de datos. • Consumo de recursos en tiempo de ejecución debido al “caching” de “blobs”, “metadata” y carga de la configuración del BDE. • Rendimiento.

58



Características de un driver de bases de datos Las distintas características ofrecidas por los estándares de conectividad a bases de datos como BDE, ODBC y JDBC pueden ser, a grandes rasgos, clasificadas en tres áreas principales: acceso a datos, obtención de “metadata” y creación de esquemas. La característica básica que un driver de bases de datos debería proveer es una interfaz para el procesamiento dinámico de consultas SQL. Las consultas SQL dinámicas permiten a una aplicación procesar cualquier consulta SQL válida en tiempo de ejecución. La mayoría de las bibliotecas cliente de los servidores SQL proveen interfaces para el procesamiento dinámico de consultas SQL como OCI o PRO *C (método dinámico 4) para Oracle, CLI para DB2 y otras fuentes de datos ODBC, CTLIB para Sybase y E7SQL para Informix. Clases principales de dbExpress Las cuatro clases principales de dbExpress son SQLDriver, SQLConnection, SQLCommand y SQLCursor. SQLMetaData es la interfaz de acceso a la información de “metadata” que está construida sobre las clases principales. Todas las clases tienen métodos para asignar u obtener valores de propiedades en tiempo de ejecución que los clientes puede utilizar para sacar ventaja de características específicas de la base de datos o para hacer un ajuste fino del acceso a datos. SQLDriver realiza procesos de inicialización específicos de la base de datos como cargar el cliente de la base de datos, inicializar el entorno y asignar los manejadores necesarios y obtener un objeto SQLConnection. SQLConnection se encarga de establecer una conexión con la base de datos, obtener un objeto SQLCommand para el procesamiento de consultas y procedimientos almacenados, obtener un objeto SQLMetaData para la obtención de información de “metadata” y manejar transacciones. SQLCommand provee métodos para el procesamiento de consultas y procedimientos almacenados y devuelve un objeto SQLCursor si hay uno disponible. También soporta la ejecución de una consulta preparada varias veces junto con los parámetros devolviendo varios cursores para el caso de procedimientos almacenados. SQLCursor mantiene datos y “metadata” de acuerdo a la consulta o procedimiento almacenado ejecutado y posee métodos para obtener individualmente los valores de los campos. SQLMetaData es la interfaz que define los distintos tipos de “metadata” que pueden ser obtenidos en una conexión abierta. El método getSQLMetaData() del objeto SQLConnection devuelve un objeto SQLMetaData. SQLMetaData provee sólo la información de “metadata” requerida por MIDAS y por los componentes de acceso a datos de Kylix, Delphi y C++Builder. El resto de la información de “metadata” no fue incluida para hacer la interfaz más simple, aunque la mayor parte de ella puede ser obtenida utilizando las opciones del objeto SQLMetaData sin necesidad de cambiar la interfaz. Mapeo de tipos de datos Las fuentes de datos representan datos en distintos formatos y una interfaz común como dbExpress debería proveer un conjunto de tipos de datos genéricos para obtener individualmente los valores de los campos. dbExpress define un conjunto lógico de

58



tipos de datos que soportan la mayoría de los tipos de datos soportados por los distintos servidores SQL. Estos tipos de datos lógicos coinciden con los de la BDE por cuestiones de compatibilidad y para que las aplicaciones existentes puedan adaptarse fácilmente a ellos. Sin embargo, el mapeo de SQL a los tipos de datos lógicos no necesariamente es el mismo que en el BDE, como por ejemplo, el nuevo tipo de dato “fldDATETIME” que fue introducido para representar el tipo de dato “timestamp” sin pérdida de información. De manera similar, datos numéricos que no caben en el tipo “double” son mapeados directamente al tipo “BCD” eliminando la necesidad de habilitar o deshabilitar “BCD”. Aún cuando hay una traducción de SQL a los tipos de datos lógicos y viceversa el impacto en el rendimiento es mínimo. Internamente, dbExpress mapea cada tipo de dato SQL en un tipo de dato físico y uno o más tipos de datos físicos son mapeados en tipos de datos lógicos. A diferencia del BDE, dbExpress no expone los tipos de datos físicos a los clientes, aunque como están las cosas hoy los desarrolladores de drivers de bases de datos pueden elegir devolver tipos de datos físicos si así lo desean. MyBase: Motor de bases de datos personal basado en XML MyBase ofrece persistencia de datos en archivos con formato XML. Permite simplificar y optimizar la distribución y el intercambio de datos. Con Kylix es posible construir aplicaciones para Internet que permitan distribuir rápidamente los datos a través de la web y construir aplicaciones flexibles y ampliables que soporten la nueva onda de aplicaciones e-commerce para Internet. MyBase se carga completamente en memoria lo que ofrece un rendimiento excelente en tiempo de ejecución. Con MyBase no es necesario distribuir archivos adicionales al ejecutable lo que elimina problemas de configuración del lado del cliente. Además, el ejecutable sólo es 300Kb más grande. MyBase soporta SQL ANSI 92 lo que permite desarrollar aplicaciones listas para escalar a cliente/servidor que accedan a servidores SQL. Además, MyBase está basado en el componente ClientDataSet lo que facilita aún más la escalabilidad de aplicaciones que utilicen MyBase. MyBase también soporta todos los tipos de datos SQL incluyendo campos BLOBs sin restricciones de tamaño.

Conclusiones

Kylix es la primera y única herramienta de desarrollo rápido de aplicaciones para el sistema operativo Linux. Kylix es Delphi y C++Builder para Linux. Los puntos más destacados de Kylix son:

• Desarrollo de aplicaciones nativas Linux. • Entorno de desarrollo visual basado en componentes. • Soporte para MySQL, InterBase, Oracle y DB2, para el desarrollo de

aplicaciones de bases de datos cliente/servidor. • Soporte de Apache, para el desarrollo de aplicaciones para Internet. • Combinado con Delphi, Kylix permite el desarrollo de aplicaciones

multiplataforma para Windows y Linux. Kylix está certificado para RedHat Linux 6.2 ó superior, Mandrake 7.0 ó superior y SuSE 7.0 ó superior.

58



58



Parte II. Aplicaciones de bases de datos con Kylix

Un poco de historia

Por mucho tiempo, el BDE fue una solución excelente para el desarrollo de aplicaciones de bases de datos, sobre todo a la hora de acceder a tablas locales. Sin embargo, a medida que la tecnología cliente/servidor se hizo más popular, el BDE poco a poco dejó de ser lo que era para convertirse en una solución “buena” con limitaciones funcionales y problemas de rendimiento. Cuando el proyecto Kylix se hizo realidad, los ingenieros de Borland se vieron obligados a tomar una decisión crucial: elegir entre migrar el BDE a Linux con todas sus limitaciones y problemas o aprovechar la oportunidad para desarrollar algo nuevo, más potente que el BDE, portable y, lo más importante, orientado a servidores SQL. La decisión no fue muy difícil de tomar, y así surgió dbExpress. Tanto Kylix como Delphi 6 incluirán DBE como una nueva alternativa de acceso a datos. Esto significa que a las tres alternativas ya existentes en Delphi 5, se sumará una: los componentes basados en DBE. Este cambio no será difícil de asimilar por los programadores Delphi, ya que es algo muy parecido a lo que ya ocurrió con Delphi 5, y de la misma forma que los componentes de acceso nativo a ADO e InterBase incluyen equivalentes a los basados en el BDE - lo cual, dicho sea de paso, facilitó mucho su utilización en nuevos proyectos -, los componentes basados en DBE también tendrán sus equivalentes a los basados en el BDE. Por lo tanto, en Delphi 6 habrá 4 alternativas diferentes de acceso a datos, de las cuales sólo una (DBE) permitirá la creación de proyectos multiplataforma, que podrán ser portados de Windows a Linux o de Linux a Windows directamente.

Me “caching” los datos

Si bien la aparición de nuevos componentes constituye un cambio importante en sí mismo, este no será el más importante que tendremos que afrontar. La gran novedad estará dada por el hecho de que DBE no soportará “caching” de datos. ¿Qué significa esto? Veamos un ejemplo que nos ayude a comprenderlo. Creemos un formulario que nos permita visualizar en una rejilla los datos de la tabla Country del alias IBLocal del BDE. Para obtener los datos, navegar a través de ellos y realizar altas, bajas y modificaciones utilizaremos un componente Table y un control DBNavigator, conectados mediante el correspondiente DataSource. La Figura 1 muestra el formulario con las propiedades que nos interesan.

58



Figura 1 – Cliente/Servidor. object Form1: TForm1 object DBGrid1: TDBGrid DataSource = DataSource1 end object DBNavigator1: TDBNavigator DataSource = DataSource1 end object Table1: TTable Active = True DatabaseName = 'IBLocal' TableName = 'COUNTRY' end object DataSource1: TDataSource DataSet = Table1 end end Al estar accediendo a un servidor SQL (en este caso InterBase) y utilizar un componente Table, el BDE se encarga por detrás del telón de generar las sentencias SQL correspondientes para seleccionar (SELECT), insertar (INSERT), borrar (DELETE) y actualizar (UPDATE) los datos. Si observamos detenidamente el comportamiento de la aplicación, veremos que se registra actividad contra la base de datos sólo cuando realizamos algunas de las acciones anteriormente mencionadas, es decir, cuando seleccionamos, insertamos, borramos o modificamos datos. Sin embargo, cuando navegamos a través de ellos no se registra actividad alguna. Esto lo podemos comprobar si observamos el puntero del ratón. Cuando el BDE está accediendo al servidor SQL cambia el puntero del ratón a un reloj de arena con la palabra SQL en la parte inferior. La ausencia de actividad contra la base de datos se debe a que el BDE almacena en memoria una copia local de los datos, es decir, soporta “caching” de datos. En cuanto el conjunto de datos completo ha viajado desde la base de datos a nuestra aplicación cliente el BDE no necesita hacer más peticiones, pues utiliza su copia local.

58



En contrapartida, DBE no soporta “caching” de datos. Funciona como si utilizáramos un componente Query con la propiedad UniDirectional puesta en True. Al no estar soportado el “caching” de datos sólo podemos navegar el conjunto de datos obtenido en una sola dirección, es decir, de principio a fin. Entonces, ¿significa esto que ya no podremos visualizar datos en una rejilla y navegar a través de ellos libremente? Si utilizáramos únicamente los componentes basados en DBE, la respuesta sería un rotundo sí. Sin embargo, ya en Delphi 3 se introdujo un componente que por sí solo (en realidad con el auxilio de una DLL) soporta “caching” de datos. Los conocedores de la tecnología MIDAS sabrán que estoy hablando del componente ClientDataSet.

Kylix & MIDAS

La gran mayoría de las aplicaciones de bases de datos desarrolladas con Kylix estarán basadas en la tecnología MIDAS. Esto significa que a los componentes que acostumbramos a utilizar para acceder a los datos tendremos que agregar otros dos: DataSetProvider y ClientDataSet. El componente DataSetProvider cumple dos funciones principales:

• obtener datos de componentes DataSet, empaquetarlos y enviarlos a componentes ClientDataSet.

• resolver las actualizaciones provenientes de componentes ClientDataSet. El componente ClientDataSet es un DataSet especializado que se diferencia de los DataSet tradicionales, como por ejemplo Table y Query, en dos aspectos:

• Obtiene los datos de un componente DataSetProvider y aplica las actualizaciones a través del mismo componente DataSetProvider.

• Soporta “caching” de datos, es decir, a medida que obtiene paquetes de datos de un DataSetProvider los almacena localmente en memoria junto con las modificaciones que realiza el usuario.

Si quisiéramos desarrollar el ejemplo anterior como lo haríamos en Kylix, deberíamos colocar en el formulario un DataSetProvider con su propiedad DataSet apuntando al Table, y un ClientDataSet con su propiedad Provider apuntando al DataSetProvider anterior. Finalmente, deberíamos modificar la propiedad DataSet del DataSource para que apunte al ClientDataSet. La Figura 2 muestra el formulario con las propiedades que nos interesan.

58



Figura 2 – MIDAS object Form1: TForm1 object Table1: TTable DatabaseName = 'IBLocal' TableName = 'COUNTRY' end object DataSource1: TDataSource DataSet = ClientDataSet1 end object DataSetProvider1: TDataSetProvider DataSet = Table1 end object ClientDataSet1: TClientDataSet Active = True ProviderName = 'DataSetProvider1' end end Al activar el ClientDataSet, éste se encargará de pedirle los datos a su DataSetProvider asociado, que a su vez se encargará de pedirle los datos a su Table asociado, que a su vez se encargará de pedirle los datos a InterBase. Luego, el DataSetProvider se hará cargo de empaquetar los datos y entregárselos al ClientDataSet, y éste los almacenará localmente en memoria. A medida que el usuario utilice la aplicación insertando, borrando y modificando datos, el ClientDataSet se encargará de almacenar esos cambios localmente en memoria. Mediante el método ApplyUpdates el ClientDataSet se encargará de empaquetar los cambios efectuados y enviárselos al DataSetProvider para que éste se encargue de aplicarlos directamente a la base de datos. Si algo anduviera mal durante la aplicación de los cambios, el DataSetProvider se encargaría de empaquetar los datos que no pudieron ser aplicados y enviárselos de vuelta al ClientDataSet para dar al usuario la posibilidad de reconciliarlos, modificándolos nuevamente y volviéndolos a aplicar o descartándolos definitivamente.

58



En un ejemplo simple como éste y con un conjunto de datos pequeño los cambios no parecen ser radicales. La única diferencia estriba en la necesidad de llamar al método ApplyUpdates del ClientDataSet para aplicar todas las modificaciones en la base de datos. Si alguna vez ha utilizado actualizaciones en caché (“cached updates”), pensará que prácticamente no hay cambios con respecto a esta tecnología. Pero como ocurre siempre con este tipo de cosas, la vida real nos plantea situaciones mucho más complejas. Veamos algunas de ellas.

Conjuntos de datos grandes

Por defecto, el componente ClientDataSet pide a su proveedor todos los registros del conjunto de datos. Si el conjunto de datos es grande, entonces la aplicación se tomará su tiempo hasta que los datos lleguen al ClientDataSet. Este tiempo será aún mayor al que se necesita, por ejemplo, con un componente Table, debido al tiempo adicional que le lleva al DataSetProvider empaquetar los datos. Para disminuir estos tiempos de respuesta tan largos, lo que podemos hacer es indicarle al ClientDataSet que no pida un paquete con todos los registros, sino que pida paquetes con una cantidad reducida de registros. La propiedad PacketsRecords nos permite indicarle al ClientDataSet la cantidad de registros por paquete que debe solicitar. De esta manera, en lugar de tener un tiempo de respuesta largo cuando solicitemos los datos por primera vez tendremos tiempos de respuesta más cortos entre peticiones de paquetes. Sin embargo, la cosa no es tan simple. Si le damos al usuario la posibilidad de navegar a través de los datos con una rejilla, entonces corremos el riesgo de que quiera posicionarse en el último registro, para lo cual el ClientDataSet no tendrá otro remedio que pedir todos los registros. Si el conjunto de datos es grande, seguramente el usuario de nuestra aplicación nos agradecerá sobremanera recordando a todos nuestros familiares, por el tiempo que le damos para que pueda tomarse un café. Otro problema similar puede surgir a la hora de insertar registros. Si el usuario inserta un registro que de acuerdo al índice activo quedaría ubicado cerca del final del conjunto de datos, al hacer ApplyUpdates el ClientDataSet intentaría posicionarse en ese registro, para lo cual no tendría otra opción que pedir todos los registros anteriores al recién insertado. Venga otro café para el usuario de nuestra aplicación. ¿Mi madre? Bien, gracias.

Concurrencia

Como ocurre con el uso de las actualizaciones en caché, las posibilidades de concurrencia se ven ampliamente incrementadas con MIDAS. Un usuario puede pasarse horas insertando, borrando y modificando datos sin enterarse de que otros usuarios pudieron haber borrado o modificado los mismos datos. Concretamente, para un usuario determinado, si entre el momento en que el ClientDataSet obtuvo el conjunto de datos y el momento en que las actualizaciones son aplicadas en la base de

58



datos otro usuario actualizó alguno de los registros que el primer usuario intenta actualizar, estaremos en presencia de un problema de concurrencia. Cuando el DataSetProvider aplica las actualizaciones en la base de datos genera las sentencias SQL para insertar, borrar y modificar registros. La manera en que se generan estas sentencias SQL es controlada por la propiedad UpdateMode del proveedor. El valor de esta propiedad determina qué campos del conjunto de datos serán incluidos en la cláusula WHERE de las sentencias SQL serán generadas. Los valores posibles de esta propiedad son:

• upWhereAll: en este caso, todos los campos del conjunto de datos serán incluidos en la cláusula WHERE. Esto garantiza que si un usuario intenta actualizar un registro que ha sido modificado por otro usuario la actualización no se aplicará.

• upWhereChanged: sólo los campos que el usuario ha modificado, más los que forman la clave primaria, serán incluidos en la cláusula WHERE. En este caso, si un usuario intenta actualizar un registro que ha sido modificado por otro usuario pueden darse dos situaciones:

o Si algunos de los campos modificados por ambos usuarios coinciden, entonces la actualización no se aplicará.

o Si ninguno de los campos modificados por ambos usuarios coinciden, entonces la actualización se aplicará.

• upWhereKeyOnly: sólo los campos que forman la clave primaria serán incluidos en la cláusula WHERE. En este caso, la actualización siempre se aplicará (salvo que se modifique la clave primaria), pero en la base de datos quedarán las modificaciones aplicadas por el último usuario.

Es posible lograr el mismo efecto para cada campo individual del DataSet a través de la propiedad ProviderFlags. Los posibles valores de esta propiedad son los mismos que para UpdateMode, con un valor adicional que no viene al caso explicar en este momento. En el caso de que las modificaciones a uno o más registros no se hayan aplicado, el DataSetProvider empaquetará los registros que no han sido actualizados y se los enviará al ClientDataSet para darle al usuario la posibilidad de resolver el conflicto. El método ApplyUpdates del ClientDataSet recibe un parámetro que indica la cantidad máxima de errores tolerable antes de cancelar el proceso de actualización. Si el valor es –1, no hay límite para la cantidad de errores tolerable. Si el valor es mayor que –1, al llegar al límite de errores especificado el proceso de actualización será cancelado prematuramente. Como ya se ha dicho, el componente ClientDataSet mantiene un registro de los cambios realizados por el usuario. El método ApplyUpdates empaqueta dichos cambios y se los envía al DataSetProvider. ApplyUpdates devuelve la cantidad de errores ocurridos, es decir, la cantidad de registros que no pudieron ser actualizados. Los registros actualizados con éxito son eliminados del registro de cambios, mientras que los registros que no fueron actualizados no lo son. Esto significa que tanto los registros que no fueron actualizados por errores como aquellos que no fueron

58



actualizados por haberse alcanzado el límite de errores tolerable siguen existiendo en el registro de cambios después de una llamada a ApplyUpdates.

Relaciones maestro / detalle

En MIDAS las relaciones maestro/detalle son manejadas de una manera especial. La razón principal para ello es que la actualización del registro maestro junto con sus respectivos registros detalle debe ser realizada en el contexto de la misma transacción, de manera que se grabe todo, es decir, maestro y detalles, o que no se grabe nada. Entonces, ¿cómo es la cosa? Bastante simple. En primer lugar, las relaciones maestro/detalle deben ser creadas del lado de los DataSet que acceden a la base de datos y no del lado de los ClientDataSet. Cuando el DataSetProvider detecta que el DataSet asociado es maestro de otro, entonces coloca en un único paquete los registros del maestro y los registros del detalle. Para cada registro del maestro se crea un campo adicional en el que se almacenan todos los registros asociados del detalle. Del lado de los ClientDataSet, si observamos los campos del ClientDataSet maestro veremos que, además de los campos correspondientes al DataSet maestro, hay un campo adicional de tipo TFieldDataSet, que no es ni más ni menos que un DataSet especial con todos los registros del detalle asociados al registro maestro. ¿Cómo accedemos a ellos? Pues a través de la propiedad DataSetField del ClientDataSet. Colocamos un segundo ClientDataSet para los registros del detalle, y en lugar de asociarlo con un DataSetProvider lo asociamos con el FieldDataSet del ClientDataSet maestro mediante la propiedad DataSetField. Para que este mecanismo funcione, debemos crear el FieldDataSet como campo persistente en tiempo de diseño.

Figura 3 – Maestro/Detalle

58



Object Form1: TForm1 object Table1: TTable DatabaseName = 'IBLocal' TableName = 'COUNTRY' end object DataSource1: TDataSource DataSet = ClientDataSet1 end object DataSetProvider1: TDataSetProvider DataSet = Table1 end object ClientDataSet1: TClientDataSet Active = True ProviderName = 'DataSetProvider1' object object ClientDataSet1Table2: TDataSetField FieldName = 'Table2' end end object DataSource2: TDataSource DataSet = Table1 end object Table2: TTable DatabaseName = 'IBLocal' IndexFieldNames = 'COUNTRY' MasterFields = 'COUNTRY' MasterSource = DataSource2 TableName = 'CUSTOMER' end object ClientDataSet2: TClientDataSet Active = True DataSetField = ClientDataSet1Table2 end object DataSource3: TDataSource DataSet = ClientDataSet2 end end De esta manera, los registros del detalle constituyen en su conjunto el valor de un campo del registro maestro. Esto significa que si modificamos un registro del detalle también estaremos modificando el registro maestro. Haga la prueba y verá que si edita un registro del detalle, el ClientDataSet maestro también pasará a modo dsEdit. Ahora al llamar al método ApplyUpdates el registro maestro y sus respectivos registros detalle serán actualizados en el contexto de la misma transacción. Si ocurriera algún error durante la actualización, la transacción sería cancelada manteniéndose la integridad de la base de datos.

58



Supongo que habrá notado que la rejilla del ClientDataSet maestro muestra el FieldDataSet. El componente DBGrid ofrece soporte para conjuntos de datos anidados como los que se utilizan en MIDAS para las relaciones maestro/detalle. Si intentamos editar este campo en la rejilla veremos que aparece un botón con tres puntos suspensivos, que al ser pulsado abre un nuevo formulario con una rejilla mostrando los registros del DataSet anidado. Es una lástima que en este formulario no se incluya un DBNavigator.

Actualizaciones personalizadas

Muy bien. El DataSetProvider ofrece un mecanismo de actualización que nos ahorra mucho trabajo. Pero ¿qué pasa si dicho mecanismo no nos sirve? Fiel a su filosofía, Delphi nos permite personalizar todo hasta el más mínimo detalle. Veamos algunos casos. El DataSetProvider tiene una propiedad llamada ResolveToDataSet que nos permite modificar completamente el mecanismo de actualización. Por defecto el valor de esta propiedad es False, lo que significa que el DataSetProvider se encargará de resolver las actualizaciones por su cuenta. Pero si le asignamos el valor True entonces el DataSetProvider aplicará las actualizaciones al DataSet asociado, como si todas las acciones sobre el ClientDataSet se hicieran sobre este DataSet. Esto nos da la posibilidad de aprovechar los eventos del DataSet ya sea para realizar validaciones o para actualizar otros DataSet. Si los cambios que queremos introducir no son tan radicales, en lugar de asignar True a la propiedad ResolveToDataSet podemos hacer uso de los eventos del DataSetProvider, que por cierto son muchos. Sin embargo, la mayoría de estos eventos están pensados para el modelo de tres capas que es posible desarrollar con MIDAS, sobre todo en lo que tiene que ver con la comunicación entre el DataSetProvider y el ClientDataSet. Tenga en cuenta que en el modelo de tres capas ambos componentes se hallan en aplicaciones distintas que estarán ejecutándose, muy probablemente, en distintos ordenadores. El evento OnUpdateData se dispara antes de que el proceso de actualización comience. El parámetro DataSet es un ClientDataSet con los cambios a aplicar. En este evento podemos recorrer este conjunto de datos cliente para obtener información sobre las actualizaciones que serán aplicadas e incluso modificarlas. El evento BeforeUpdateRecord se dispara antes de que las actualizaciones de cada registro sean aplicadas. Este evento recibe varios parámetros. SourceDS es el DataSet asociado al DataSetProvider. DeltaDS es un ClientDataSet con el registro a ser actualizado. UpdateKind es el tipo de actualización que se realizará y Applied indica si la actualización debe ser aplicada o nosotros nos encargamos de hacerlo en este evento. BeforeUpdateRecord brinda la posibilidad de ejecutar cualquier conjunto de instrucciones antes de que se apliquen las actualizaciones de cada registro.

58



El evento AfterUpdateRecord es similar a BeforeUpdateRecord pero, como su nombre indica, se dispara después de que las actualizaciones a cada registro han sido aplicadas. Los parámetros son los mismos, exceptuando a Applied. Por último, el evento OnUpdateError se dispara para cada registro que no pueda ser actualizado debido a un error. El parámetro DataSet es el ClientDataSet que contiene el registro que no pudo ser actualizado. E es una excepción del tipo TUpdateError que podemos utilizar para obtener información sobre el error ocurrido. UpdateKind es el tipo de actualización que se intentó aplicar para el registro que generó el error. Response nos permite indicar la acción que debe realizar el DataSetProvider al salir del evento. Explicar los detalles de cada uno de estos eventos sobrepasa los límites de este artículo. La intención es simplemente mencionarlos para mostrarle en qué medida es posible personalizar el mecanismo de actualización del DataSetProvider.

Conclusiones

Para los programadores de Delphi, el Borland Database Engine o BDE forma parte de nuestras vidas. Con sus ventajas y desventajas, con sus soluciones y problemas, ya estamos acostumbrados a él. Sin embargo, como lo único constante es el cambio, con el proyecto Kylix le llegó su turno al BDE. Su sustituto, Database Express o DBE, nos obligará a modificar la manera en que desarrollamos aplicaciones de bases de datos. La razón principal es que DBE no soporta “caching” de datos. Por este motivo, la tecnología MIDAS será la piedra angular de las aplicaciones de bases de datos en Kylix. Es posible que Ud. nunca antes haya utilizado los componentes de la página MIDAS de la Paleta de Componentes, ya sea porque nunca los necesitó, porque no tuvo tiempo o no sintió la suficiente curiosidad, o simplemente porque no tiene la versión Enterprise de Delphi. Lo cierto es que si tiene planes de migrar sus aplicaciones a Kylix, entonces es hora de que comience a experimentar con la tecnología MIDAS. Como con toda nueva tecnología (nueva para los que no la conocen, ya que MIDAS fue introducida en Delphi 3), tendrá que enfrentarse con nuevos problemas que requerirán nuevas soluciones. A lo largo de este artículo hemos visto cómo utilizar los componentes DataSetProvider y ClientDataSet para desarrollar aplicaciones de bases de datos como lo haríamos con Kylix. También hemos presentado algunos de los problemas con los que nos deberemos enfrentar, y cómo solucionarlos o minimizar sus efectos. Sin embargo, todavía queda mucha tinta en el tintero y poco a poco la iremos utilizando para conocer más a fondo la tecnología MIDAS.

Parte III. Desarrollo Web con Kylix Edición Server

Aplicaciones Web Kylix Kylix está capacitado para la creación de aplicaciones para el servidor Web Apache utilizando tanto extensiones CGI como DSO (Dynamic Share Objects). La figura 1 muestra el cuadro de diálogo del asistente ‘Web Server Application’ al que se puede acceder seleccionando File | New desde el menú principal.

Figura 1. Cuadro de diálogo del asistente “Web Server Application”. Una aplicación Kylix WebBroker tendrá un código compatible con Delphi 6, el cual permitirá compilar extensiones para ISAPI, NSAPI, y win-CGI para servidores Web diferentes de Apache. Esta compatibilidad de código viene dada gracias a la arquitectura común WebBroker (NetCLX) que es utilizada para la estructura de la aplicación Web. La arquitectura de WebBroker es también independiente del servidor Web con el fin de proteger a los desarrolladores del servidor Web subyacente. El Servidor Web Apache El software servidor de Web más popular en Linux es Apache. De hecho, es uno de los servidores Web más utilizados en el mundo no sólo en Linux, sino también en plataformas como Windows y Unix. Apache creció a partir del proyecto ‘NSCA httpd’ desarrollado por el “National Centre for Supercomputing Application” en Illinois. Varios autores que enviaron parches para el servidor httpd de NCSA formaron juntos el grupo Apache (http://www.apache.org). La primera versión pública oficial (0.6.2) del servidor Apache apareció en abril de 1995. Con el paso del tiempo pasaron a llamarse “La Fundación del Software Apache”, siendo una compañía sin animo de lucro que crea código abierto. Creando una aplicación CGI para un Servidor Web Apache

58



En este ejemplo práctico se creará un sencillo CGI que puede ser utilizado para enviar e-mails desde el navegador Web. Generará un formulario HTML inicial desde el cual un usuario puede rellenar los datos del e-mail y lo devuelve a la aplicación servidora. La aplicación Web lo creará entonces y enviará un e-mail basado en la información que el usuario proporciona en el formulario. Teniendo seleccionado File | New en el menú principal de Kylix, elegiremos la opción CGI en el asistente de aplicaciones servidoras Web – ver Figura 1. Kylix entonces creará una nueva aplicación de consola ‘no GUI’ con una unit, un WebModule, ver Figura 2. El WebModule gestiona todas las peticiones desde el servidor Web y es donde se pueden poner los componentes no visuales, produciendo el contenido, dentro de la aplicación Web.

Figura 2. Un WebModule vacío.

Ahora colocamos un TPageProducer, desde la pestaña Internet de la paleta de componentes (ver Figura 3) dentro del WebModule (ver Figura 4) estableciendo su propiedad HTMLDoc, utilizando el Object Inspector, al HTML requerido (ver Figura 5) para el formulario del correo electrónico. El HTML usado se crea separadamente y se pega dentro de la propiedad HTMLDoc. Como con todas las propiedades, usted tiene la flexibilidad de poder poblar HTMLDoc en el momento de ejecutarse. Vea que la propiedad PageProducer Name se ha cambiado a ‘EmailForm’ usando el Object Inspector (ver Figura 6).

Figura 3. La paleta de componentes Internet.

Figura 4. Un WebModule con PageProducer.

<html> <body bgcolor="#CCCC99"> <form method="post" action="/cgi-bin/emailform"> <br> E-mail address<br> <input type="text" name="address" size="50"><br> Message<br> <input type="text" name="message" size="50"><br> <br>

58



<input type="submit" name="Submit" value="Enviar e-mail"> </form> </body> </html> Figura 5. El HTML necesario para un formulario de correo electrónico.

Figura 6. El Object Inspector.

Cada aplicación WebBroker mantiene una lista de ‘acciones’. Estas están activadas coincidiendo con las peticiones http recibidas por la aplicación Web con el método MethodType y las propiedades PathInfo de cada acción listada. Podría no haber ninguna petición de acción que este configurada dentro de su aplicación, entonces se puede llamar a una acción por defecto – ver Figura 7. Esto se puede hacer de la siguiente manera: añada una acción al WebModule haciendo clic en el icono New Action sobre el Action Editor y ponga la propiedad Default en ‘True’ utilizando el Object Inspector. A continuación, ponga la propiedad Producer para el ‘EmailForm’ PageProducer (ver Figura 7). La acción predeterminada de esta aplicación web será ahora devolver el formulario del Correo electrónico al navegador cliente.

Figura 7. Una lista de acciones WebModule con la acción por defecto asignada. La siguiente tarea es añadir otra acción para gestionar la petición de ‘Send e-mail’ cuando el botón del formulario HTML sea presionado (ver Figura 8). Note aquí que el desencadenante para la acción es el MethodType de mtPost correspondiente al método del formulario HTML de e-mail.

58



Figure 8. Una acción de la lista WebModule con acción mtPost.

Un componente TIdSMTP se agrega al WebModule mostrado en la Figura 9. Éste es uno de los componentes del conjunto de componentes Indy incluido con Kylix. Este componente es utilizado para enviar e-mails vía SMTP a un servidor de correo, en este caso un servidor local de correo MTA.

Figura 9. Un WebModule con un componente TIdSMTP Indy añadido.

El gestor de eventos OnAction para la acción de enviar el e-mail de web necesita cierta información. Necesita leer la dirección y los valores del mensaje dentro de la petición de HTTP enviada desde el formulario y envía un correo electrónico que usa el componente TIdSMTP, ver Figura 10. procedure TwebModule1.WebModule1Actions1Action(Sender: TObject; Request: TwebRequest; Response: TWebResponse; var Handled: Boolean); begin try IdSMTP1.QuickSend( 'localhost', 'subject', Request.ContentFields.Values['Dirección'], '[email protected]', Request.ContentFields.Values['Mensaje'] ); Response.Content := 'E-mail enviado correctamente'; except On E:Exception do Response.Content := 'Error enviado e-mail<br>' + E.Message; end; end; Figura 10. Método OnAction para enviar un e-mail.

Este es el código de la aplicación completo. Para hacer que la aplicación trabaje con el servidor web Apache, necesitamos compilar el proyecto y copiar el ejecutable resultante al directorio /cgi-bin del servidor web Apache. Puede preferir utilizar en el menú principal Projects | Options… y entonces seleccionar la pestaña Directories, poner el encaminamiento de salida directo a su directorio / cgi-bin. Una consideración en la configuración de su servidor Apache es el fichero httpd.conf (http daemon configuration.) Este archivo necesitará algunas entradas adicionales, ver Figura 11. Tenga en cuenta que puede haber ya una entrada del Directorio en su httpd.conf para un /cgi-bin, en ese caso no hay ninguna necesidad de duplicar, simplemente verifique que tiene la configuración similar a la que se muestra en la Figura 11. Fíjese también

58



que dependiendo de la distribución de Linux que usted está usando su directorio /cgi-bin puede estar en una ruta diferente. <Directory /usr/local/apache/cgi-bin> AllowOverride None Options ExecCGI Order allow,deny Allow from all </Directory> SetEnv LD_LIBRARY_PATH /opt/kylix/bin SetEnv LANG en_US Figura 11. Las entradas de httpd.conf requeridas por Apache para ejecutar las aplicaciones CGI de Kylix.

Las variables de entorno LD_LIBRARY_PATH y LANG son requeridas como una aplicación Web CGI de Kylix que necesita usar los ficheros binarios de Kylix .so (shared object) para ejecutarse dentro de Apache. El comando SetEnv establece una variable de entorno con los pasos Apache para la aplicación CGI cuando se ejecuta. El propietario, grupo y permisos de los ficheros Kylix .so y el ejecutable de la aplicación Web CGI necesitarán estar establecidos apropiadamente por Apache. Con Apache usted normalmente establece un usuario y un grupo con los usos de Apache para todas las peticiones Web. Busque los comandos User y Group en su fichero httpd.conf. De este modo, cualquiera que se conecte a su servidor web entra de hecho registrado como usuario. Para que este usuario utilice una aplicación Web CGI de Kylix tiene que ser accesible y ejecutable por el usuario Apache. El usuario de Apache debe mantenerse con los mínimos derechos para aumentar la seguridad del servidor. Por ejemplo, si su usuario Apache es ‘apache’ en el grupo ‘apache’ y usted ha creado una aplicación Web CGI Kylix llamada ‘emailform’ quizás tenga que introducir los comandos indicados en la Figura 12 para que su aplicación Web sea accesible. Tenga en cuenta que posiblemente necesite registrarse como root para poder hacerlo. cd <your cgi-bin directory> chown apache emailform chgrp apache emailform chmod 755 emailform Figura 12. Configurando propietario y grupo para la aplicación CGI ‘emailform’ para que funcione correctamente con Apache.

Lo mismo se aplica para compartir objetos del directorio Kylix/bin, podría tener que cambiar el propietario, grupo y permisos. Una sugerencia que le comentamos para mantener una web ‘viva’ es copiar el directorio Kylix/bin fuera del entorno de desarrollo dentro de un entorno vivo. Podría establecer el propietario, grupo y permisos, y configurar apropiadamente el LD_LIBRARY_PATH a ese directorio para mantener la seguridad de su servidor Web Apache. Las Figuras 13 y 14 muestran la aplicación web ejecutándose en un navegador, en este caso KDE Konqueror, aunque lógicamente se podría haber utilizado cualquier otro navegador.

58



Figura 13. La aplicación web emailform ejecutándose en un navegador, antes de enviar el e-mail.

Figura 14. La aplicación web emailform ejecutándose en un navegador, después de enviar el e-mail.

Intente hacerlo usted directamente y verá que crear una aplicación Web CGI para Apache con Kylix es un proceso rápido y sencillo. Tour por WebBroker WebBroker (parte de NetCLX) proporciona una arquitectura de plataforma cruzada para aplicaciones servidoras Web de Internet conforme a los estándars http. La arquitectura WebBroker es independiente del servidor a la hora de extraer y encapsular esos estándars http en una estructura de clase común. Con Kylix y WebBroker es posible soportar las especificaciones de aplicaciones CGI y DSO (Dynamic Shared Objects) de Apache. Las aplicaciones Kylix WebBroker tendrán un código compatible con Delphi 6, el cual podrá compilar extensiones para ISAPI, NSAPI, y win-CGI para otros servidores Web. Es importante entender las clases de objetos más importantes de la arquitectura de WebBroker, esta arquitectura crea la estructura de sus aplicaciones dejando el foco del ‘contenido de negocio’ así como los detalles técnicos del código en sus manos.

58



La clase TWebDispatcher

TWebDispatcher es el hub de cualquier aplicación Web, es la clase que se conecta a sí misma en el servidor Web. Sólo puede añadirse un gestor de mensajes (Dispatcher) Web por cada aplicación. El propósito es recibir los mensajes de peticiones http y que el gestor de eventos los pase al método ‘action’ apropiado que entonces ensamble el contenido y devuelva la respuesta. El TWebDispatcher envía en ese momento la respuesta de vuelta al cliente. Las acciones ocurren en el formulario de una colección de TWebActionItem. La Figura 15 muestra las propiedades más significativas de TWebDispatcher. Property Actions: TWebActionItems; Property Request: TWebRequest; Property Response: TWebResponse; Figura 15. Propiedades más significativas de TWebDispatcher.

El WebModule

Un WebModule encapsula, crea y gestiona las aplicaciones TWebDispatcher proporcionando un diseño de interfaz de tiempo por medio del Object Inspector para la lista de TWebActionItem y eventos a nivel de aplicación (ver Figura 16). También puede permitir colocar cualquier componente no visual dentro de un TWebModule, así como el componente TIdSMTP utilizado en la primera aplicación de ejemplo. Property AfterDispatch; Property BeforeDispatch; Property OnCreate; Property OnDestroy; Property OnException; Figura 16. Un gestor de eventos WebModule.

La clase TWebActionItem

Un TWebActionItem es utilizado para responder a un particular tipo de mensaje de petición de HTTP identificado por el encaminamiento URL y el método de petición HTTP. El TWebDispatcher elige la acción o acciones apropiadas para la petición HTTP haciendo coincidir el encaminamiento y tipo de método de la URL con el PathInfo y la propiedad MethodType. Esto es posible para adjuntar cualquier productor a un TwebActionItem mediante la propiedad Producer. El productor es utilizado para formar una respuesta HTTP a la acción o el método del gestor de eventos OnAction que puede codificarse directamente por el desarrollador. La Figura 17 muestra las propiedades más significativas de TWebActionItem. Property Default: Boolean; Property Enabled: Boolean; Property MethodType: TMethodType; Property PathInfo: String; Property Producer: TCustomContentProducer;

58



Property OnAction; Figura 17. Propiedades y eventos más significativos de TWebActionItem.

Las peticiones y respuestas HTTP se emparejan juntas y se pasan al productor o gestor de eventos OnAction como objetos TWebRequest y TWebResponse, la Figura 18 muestras el encabezado para un método de gestor de evento OnAction. Procedure TWebModule1.WebModule1Actions1Action(Sender: TObject; Request: TWebRequest; Response: TWebResponse; var Handled: Boolean); Figura 18.Cabecera del método de gestor de evento TWebActionItem.

La clase TWebRequest

TWebRequest es la clase base para todos los objetos que representan peticiones del cliente que se pasan a una aplicación del servidor Web. TWebDispatcher crea TWebRequests para capturar las peticiones del cliente. Captura cualquier posible petición comprensible que un servidor Web podría recibir incluyendo cosas como Cookies, contenidos codificados y valores de campo, valores de consultas, tipos de métodos, fechas de vencimiento, los tipos de medios de cliente, peticiones en caché, versiones de protocolos, versiones de contenidos, URI, y mucho más.

La clase TWebResponse

Use un heredero de TWebResponse para especificar la respuesta a un mensaje de petición HTTP. El TWebDispatcher crea un TWebResponse adecuado para el objeto TWebRequest de una petición de HTTP. Este par TWebRequest y TWebResponse se pasan a la acción correspondiente para que el contenido de la respuesta pueda formularse. De nuevo un TWebResponse captura cualquier posible respuesta, incluso cosas como tipos MIME, Cookies, contenido HTTP, estado de la respuesta, fecha del vencimiento, etc.

La clase TCustomContentProducer

TCustomContentProducer es la clase base para todos los objetos que producen el contenido que se envía al cliente en la contestación a las peticiones de HTTP. El contenido puede ser una cadena HTML, XML, WML o tipo MIME. Algunos herederos de TCustomContentProducer son: Componente Descripción TPageProducer Productor de contenido de una plantilla HTML simple TDataSetTableProducer Produce una tabla HTML que muestra los registros en un dataset TDataSetPageProducer Productor de la página de datos, que puede usar un dataset para

poblar los tags transparentes HTML TSQLQueryTableProducer Produce una tabla HTML para los registros de parametrización

58



de consultas SQL. La consulta obtiene los parámetros desde una petición HTTP

Los productores de contenidos reconocen los tags especiales en su HTML asociado que aparecen como <#tag>. El contenido es solicitado desde el productor y cuando encuentra un <#tag> el evento OnHTMLTag es lanzado donde el tag puede ser reemplazado por contenido. Por ejemplo, tome un TPageProducer con su propiedad HTMLDoc establecida para el HTML en la Figura 19. <html> <body> <#date format=dd.mmm.yyyy> </body> </html> Figura 19. Un # tag HTML transparente. Cuando el contenido desde este TPageProducer es solicitado podemos querer sustituir el tag <#date> con una cadena representando la fecha actual y el formato de tiempo especificado. Para hacer esto podríamos requerir un gestor de eventos OnHTMLTag como en la Figura 20. procedure TwebModule1.EmailFormHTMLTag(Sender: TObject; Tag: Ttag; Const TagString: String; TagParams: Tstrings; var ReplaceText: String); begin if ( Tag = tgCustom ) and ( TagString = 'date' ) then ReplaceText := FormatDateTime( TagParams.Values['format'], Now ); end; Figura 20. Método del gestor de eventos OnHTMLTag.

Creando aplicaciones CGI Apache utilizando DBExpress En este ejemplo práctico se creará una sencilla aplicación Web CGI que puede consultar empleados de la base de datos de ejemplo de InterBase employee.gdb. El usuario se encontrará con un formulario inicial HTML donde pueden introducir el nombre del empleado que deseen para consultar a la base de datos. Al enviar esta consulta, la aplicación Web abre una conexión a InterBase y realiza una consulta SQL. La respuesta se establece para esta consulta cuando retorna al usuario como una tabla HTML de los empleados encontrados con el nombre requerido. Creé una nueva aplicación servidora Web CGI utilizando File | New desde el menú principal y entonces seleccione el icono Web Server Application. Esto iniciará el asistente WebBroker Application, seleccione ‘CGI Stand-alone executable’ y entonces pulse OK. Una vez que tiene su WebModule, añada los siguientes componentes al WebModule… Componente Pestaña Paleta de Componentes TPageProducer TDataSetTableProducer

Internet

TSQLConnection TSQLQuery

DBExpress

58



El WebModule aparecerá como en la Figura 21.

Figura 21. Un WebModule con TPageProducer, TSQLConnections, TSQLQuery y un componente no visual

TDataSetTableProducer.

El PageProducer se usa para proporcionar una página HTML por defecto con el formulario de consulta de empleados. La Figura 22 muestra el HTML incluido dentro de la propiedad HTMLDoc. <html> <body bgcolor="#CCCC99"> <form method="post" action="/cgi-bin/qryemp"> <br> Enter employee name<br> <input type="text" name="empname" size="50"><br> <br> <input type="submit" name="Submit" value="Query"> </form> </body> </html> Figura 22. Página por defecto producida por el formulario HTML.

Dos TWebActionItem son añadidos a la propiedad de lista de acciones del WebModule (ver Figura 23). Uno es utilizado como acción por defecto así la propiedad Default se pone en True y la propiedad Producer se pone al PageProducer con el HTML por defecto. La segunda acción es para cuando el usuario consulta por un empleado desde el formulario por defecto.

Figura 23. La lista de acciones del WebModule.

Para utilizar la base de datos debemos instalar la conexión dbExpress apropiada. Para hacer esto utilizamos el editor DBExpress Connections, ver la Figura 24. Para abrir este diálogo haga ‘clic derecho’ en el componente SQLConnection del WebModule. En este caso una nueva conexión con InterBase llamada ‘IBEmployee’ ha sido añadida. Aquí la propiedad Database ha sido establecida para employee.gdb con un login de usuario ‘sysdba’ y clave ‘masterkey’. Una vez que tenga establecida una conexión es posible probarla mediante el botón de conexión de prueba ‘check’.

58



Figura 24. Editor de conexiones DBExpress.

Ahora el gestor de eventos OnAction para la acción post ha empezado a trabajar. Es utilizado para abrir una conexión DBExpress, realizando la consulta SQL y produciendo la respuesta de contenido mediante DataSetTableProducer, ver Figura 25. Para que el lector pueda ver todas las conexiones lógicas entre varios componentes, todas las conexiones deben esta hechas en tiempo de diseño vía Object Inspector. procedure TwebModule1.WebModule1Actions1Action(Sender: Tobject; Request: TwebRequest; Response: TwebResponse; var Handled: Boolean); begin {open database connection} SQLConnection1.ConnectionName := 'IBEmployee'; SQLConnection1.Open; {connect query object to database} SQLQuery1.SQLConnection := SQLConnection1; {run query against database} SQLQuery1.SQL.Text := 'select emp_no, first_name, last_name from employee '+ 'where first_name like ' + '"' + Request.ContentFields.Values[ 'empname' ] + '"'; SQLQuery1.Open; {connect producer to query} DataSetTableProducer1.DataSet := SQLQuery1; {set response content to producer} Response.Content := DataSetTableProducer1.Content; {close query and database connection} SQLQuery1.Close; SQLConnection1.Close; end;

Figura 25. El gestor de eventos OnAction abre la conexión DB, consulta y produce el contenido.

Ahora el código para esta aplicación está completo con lo que nosotros necesitamos compilar y distribuir el ejecutable resultante a la carpeta de cgi-bin del servidor Apache. Antes de compilar, debe seleccionar el menú principal Projects | Options… y entonces seleccionar la pestaña Directories, establecer el encaminamiento de salida para su directorio /cgi-bin. Y también en el fichero httpd.conf en el que necesitamos añadir la entrada apropiada como ya vimos en la primera aplicación de ejemplo. Las Figuras 26 y 27 muestran la aplicación Web ejecutándose en un navegador, en este caso KDE Konqueror. Cualquier otro navegador podría utilizarse.

58



Figura 26. Introducir el nombre del empleado a consultar.

Figura 27. Resultado de la consulta mostrado en una tabla HTML.

Trate de hacer esto usted mismo creando una aplicación de datos para Apache con Kylix y verá que es un proceso rápido y sencillo. Procesos Apache Cuando el servidor Web Apache se pone en marcha crea varias instancias de procesos del servidor. Este es un esquema claro que permite a Apache servir múltiples entradas de peticiones instantáneamente. Tecleé el comando de la Figura 28 y verá una instancia del servidor ejecutándose como raíz y otras instancias ejecutándose como usuarios Apache (como asignados en httpd.conf). ps –aux | grep apache Figura 28. Comando para ver todos los procesos en ejecución.

La copia de la raíz no sirve las peticiones dado que tendría demasiada potencia como recordamos de los problemas de seguridad. Lo que hace es actuar como copia maestra, el propósito principal es monitorizar el proceso hijo de Apache. Cada proceso hijo de Apache envía la ocupación y el estado de espera a un marcador. El proceso principal de Apache verifica este marcador, si todos los procesos hijos están ocupados y más peticiones están siendo recibidas, entonces se crean más procesos hijos para servirlas. También si hay demasiados procesos hijos esperando, los elimina. Este mecanismo es una característica de Apache Virtual Hosting y está controlado por comandos en httpd.conf como ScoreBoardFile, MaxClients, MaxRequestsPerChild, MaxSpareServers, MinSpareServers, StartServers y otros.

58



Módulos DSO Apache Un DSO es un Dynamic Shared Objects (Objetos compartidos dinámicamente) y su objetivo es similar a una DLL de Windows. Un DSO proporciona enlaces dinámicos y carga código común dentro del ejecutable al ejecutarse éste. Un ejemplo de un DSO podrían ser los ficheros .so en el directorio kylix/bin o en /usr/lib. Fíjese, .so por regla general es la extensión de fichero utilizada para indicar que un fichero es un DSO. Hay dos tipos de uso de DSO en Linux, que son compartir librerías y compartir objetos. Una librería compartida es un DSO donde un enlace estático al programa ejecutable es establecido en tiempo de construcción vía enlazador. Este proceso codifica estrictamente la librería de referencia en el ejecutable para que cuando ejecute Linux permita localizar el DSO vía encaminamiento hard-coded o encaminamientos configurados vía las variables de entorno LD_LIBRARY_PATH. Un objeto compartido es un DSO cuando un enlace es establecido sólo en tiempo de ejecución, el programa ejecutable dice a Linux que cargue un DSO dentro de su espacio de direcciones resolviendo cualquier símbolo que aparezca como enlazado estáticamente. El servidor de Web Apache se diseña con la modularidad en mente y la construcción en el núcleo es un módulo extensible API que proporciona una interfaz consistente. El volumen de las operaciones Apache se lleva a cabo en un conjunto de módulos DSO que dejan sólo un núcleo mínimo. Esto tiene varias ventajas: Es posible construir un servidor Apache que se ajuste a las funcionalidades requeridas para eliminar los módulos DSO no requeridos. Así puede mejorar el rendimiento. Los desarrolladores de terceras partes pueden fácilmente desarrollar módulos Apache utilizando el API, que amplía las funcionalidades del núcleo, por ejemplo, mod_per.so añade un interprete Perl embebido y un interfaz Perl dentro del API. Esos módulos pueden añadirse fácilmente a un servidor Apache existente. Kylix puede crear este tipo de módulos para Apache. Los desarrolladores de aplicaciones puede usar módulos en vez del sistema CGI para distribuir aplicaciones. Utilizar el API de Apache en vez del interfaz CGI proporciona una mejora de rendimiento. Kylix puede crear este tipo de módulos para Apache. Apache tiene dos formas en que se pueden cargar módulos para instalarse. Uno es compilar el ejecutable dentro de Apache, el otro es usar el comando LoadModule en httpd.conf. Tecleé el comando mostrado en la Figura 29 si desea ver qué módulos están compilados dentro de su ejecutable Apache. Note que su ejecutable Apache (httpd) puede estar en un directorio diferente. /usr/local/apache/httpd –l Figura 29. Comando para ver todos los módulos compilados dentro de Apache.

58



Para compilar módulos con el ejecutable httpd necesitará descargar e instalar el código fuente desde http://www.apache.org. El comando de la Figura 30 muestra la construcción y procedimiento de instalación para Apache con un módulo adicional. Es recomendable antes de tratar de construir Apache desde el código fuente leer toda la documentación acerca del procedimiento. cd /usr/src/apache_1.3.12 ./Configure --add-module=<mypath>/<mymodule>.c --enable-shared=<mymodule> make install Figura 30. Comando para ver todos los módulos compilados dentro de Apache.

Cargar un módulo utilizando LoadModule es más fácil. La Figura 31 muestra la entrada en el fichero httpd.conf requerida para cargar un módulo DSO para Apache. LoadModule <mymodule>_module <mypath>/<mymodule>.so Figura 31. Comando para ver todos los módulos compilados dentro de Apache.

Creando módulos DSO con Kylix Con Kylix crear un módulo DSO Apache no es diferente de crear una aplicación CGI para Apache. La única diferencia real es que tiene que seleccionar la opción ‘Apache Shared Module (DSO)’ en el asistente de aplicaciones New Web Server (ver Figura 1). Una aplicación DSO utiliza la misma arquitectura WebBroker que ya detallamos. Así desarrollar un DSO no es diferente de desarrollar cualquier otra aplicación WebBroker. El único cambio resaltable es que cuando compila su DSO Apache no crea un ejecutable sino un fichero DSO llamado lib<projectname>.so con las convenciones de nombres DSO. La diferencia con una aplicación Web DSO Apache no está en la parte visible. Hace uso de dos units de Kylix llamadas HTTPD.pas y ApacheApp.pas. La unit HTTPD.pas es un fichero de cabecera de pascal para el API de Apache. La unidad ApacheApp.pas contiene una clase llamada TApacheApplication que encapsula el gestor de peticiones WebBroker. Una aplicación WebBroker se adjunta a sí misma a Apache vía API. Kylix y XML La arquitectura WebBroker puede usarse para generar documentos XML (Extensible Markup Language) así como los HTML que ya hemos mencionado. Por ejemplo en lugar de colocar una plantilla HTML en un TPageProducer, colocar una plantilla XML. Como Delphi 5 tiene arquitectura WebBroker hay muchos artículos disponibles de cómo utilizar WebBroker con XML, los cuales se aplican igual para Kylix. A continuación le indicamos una dirección donde puede encontrar uno de esto artículos: “Generating XML and Delivering It Across the Web By Keith Wood”

58



http://www.delphizine.com/features/2000/02/di200002kw_f/di200002kw_f.asp Kylix y WAP De nuevo la arquitectura WebBroker puede ser utilizada para distribuir aplicaciones WAP (Wireless Application Protocol). En el momento actual WebBroker ya permite generar documentos WML (Wireless Markup Language). Como Delphi 5 soporta la arquitectura WebBroker hay también muchos artículos disponibles sobre el uso de WebBroker con WAP, estos se aplican igual para Kylix. A continuación le indicamos una dirección donde puede encontrar uno de esto artículos: “WAP! Delphi Does Wireless by Jani Järvinen” http://www.delphizine.com/features/2000/04/di200004jj_f/di200004jj_f.asp Conclusiones Leyendo este documento puede comenzar a ver el potencial de las aplicaciones para el servidor Web Apache e Internet que pueden ser desarrolladas utilizando Borland Kylix. Este documento actúa como una introducción de las posibilidades de Kylix trabajando para Apache. Tenemos muchos años de experiencia utilizando Delphi y Linux independientemente, y podemos decir que Kylix con Linux va a ser una combinación muy potente. Kylix con Apache forman un equipo muy escalable, que puede ser utilizado para desarrollar soluciones intranet de cualquier tamaño o soluciones de comercio electrónico críticas distribuidas sobre un cluster Linux. Con Kylix podemos ahora tener una herramienta que realmente proporcione ventajas a Linux en las empresas.

58



58



Parte IV. Cómo ve el mercado a Borland Kylix

Primeros pasos muy prometedores

Kylix es un producto muy esperado con un mercado potencial muy amplio (Linux no ha parado de crecer en los últimos años), quizás por ello y aunque aun sea pronto para conocer el alcance de su éxito, muchos fabricantes y grupos de usuarios han decidido apostar fuertemente por él, los resultados los veremos en los próximos meses, pero como anticipo y para que se vaya relamiendo le comentamos los siguientes datos que consideramos significativos:

• Las peticiones de reservas en el mundo se cuentan por cientos de miles, como dato anecdótico le comentamos que sólo en los países nórdicos (y más en concreto en Finlandia, cuna del creador de Linux) hay reservadas más de 10.000 copias por cada uno de los distribuidores.

• La mayoría de fabricantes de utilidades para Delphi y C++Builder han confirmado su migración a Kylix, otros incluso han llegado más lejos como son los que ofrecen utilidades para migrar desde Delphi o Visual Basic a Kylix garantizando un cierto nivel de calidad.

• Las editoriales también apuestan por Borland Kylix, actualmente existe un libro en castellano y dos en inglés, y se están preparando al menos cinco en inglés y dos en castellano.

• Danysoft ya tiene preparados sus primeros temarios de formación, relacionados con la introducción, migración y gestión de bases de datos con Kylix.

• En la página de Danysoft sobre Kylix www.danysoft.com/kylix.htm existe información ampliada y varios artículos técnicos, entre los que destacan: Presentación en PowerPoint de Kylix (con información sobre el interfaz gráfico, la gestión de bases de datos y el desarrollo de aplicaciones para la Web con Kylix), creación de aplicaciones WAP con Kylix, desarrollo para Apache con la edición servidor de Kylix, etc...

• Grupos de usuarios, web especializadas y artículos como este publicado en Byte que amplían la difusión de Kylix alcanzando a la totalidad de la comunidad de desarrolladores.

Pocos lenguajes han llegado al usuario con tanta expectación y tan bien arropados tanto por el prestigio del fabricante, como por la industria. Ahora la pelota esta en su tejado, ustedes y el tiempo serán los encargados de confirmar tan buenas expectativas.

58



58



Apéndice A: Configuración del Sistema utilizada para los ejemplos prácticos.

A continuación indicamos el software que fue utilizado cuando se desarrollaban los ejemplos para la Web incluidos en este documento. Lo incluimos como información adicional que puede ser interesante para los lectores:

• Distribución Linux - Mandrake 7.2 con actualización KDE 2.0. • Kylix Field Test build 3.142 • Interbase 5.6 • Apache 1.3.12 • Sendmail 8.11.0

58



58



Apéndice B: Enlaces interesantes.

A continuación le indicamos webs útiles relacionadas con Kylix y Apache: Kylix http://www.danysoft.com/kylix.htm - información sobre Kylix en Danysoft. http://borland.danysoft.com - información en Danysoft sobre soluciones Borland. http://www.danyshop.com - sistema ecommerce con libros y software para Kylix. http://www.borland.com - página principal de Borland. http://www.borland.com/kylix - página principal sobre Kylix en Borland http://wwwnevrona.com/indy - The Indy components, proyecto Open Source. http://www.delphi-jedi.org/Jedi:VOYJEDX - The Jedix page, parte del proyecto Jedi http://www.drbob42.com/kylix/ - noticias y recursos sobre Kylix Apache http://www.apache.org – “The Apache Foundation” http://www.apache.org/docs – documentación sobre Apache http://www.apacheweek.com – noticias sobre Apache http://www.oreilly.com/catalog/apache2/ - libros sobre Apache en O’Reilly http://www.modules.apache.org – “The Apache module registry” http://www.apache-ssl.org – página principal del proyecto “Apache SSL” http://java.apache.org – página principal del proyecto “Java-Apache” http://www.php.net – página principal de PHP http://perl.apache.org – página principal del proyecto de integración Apache/Perl

58



58



Apéndice C: Características.

Folleto de características técnicas de Borland Kylix.

Kylix Desarrollo Rápido de Aplicaciones para Linux. El entorno RAD de Borland Delphi y C++Builder, ahora para desarrolladores Linux. Descripción Ampliada : Funciones claves:

• Entorno de desarrollo visual • Desarrollo para el servidor web Apache • Arquitectura abierta de bases de datos • Aplicaciones compiladas de forma nativa • Librería de componentes para desarrollo en plataformas cruzadas (CLX)™ • Desarrollo Delphi™ para Linux® • Depurador completamente integrado • Distribución de aplicaciones libres de Royalty®

Desarrollo rápido de aplicaciones para Linux®. Linux® está transformando los entornos corporativos altamente competitivos de hoy en día. Con su consistencia, escalabilidad y bajo coste de adquisición, Linux es de hecho la aplicación servidora para la web y rápidamente comienza a ser una alternativa a Windows en los escritorios. El desarrollo de aplicaciones para Linux con las herramientas tradicionales es una difícil proposición. Las herramientas de desarrollo tradicionales de Linux son difíciles de aprender, y no proporcionan la productividad que espera un desarrollador corporativo acostumbrado a los rápidos ciclos de las herramientas de desarrollo para Windows®. ¡Borland® Kylix™ cambia esto! Kylix presenta el Desarrollo Rápido de Aplicaciones (RAD) para Linux. La integración de un entorno de desarrollo líder, depurador interactivo, diseñador visual intuitivo y un conjunto de componentes mejorados se combinan para darte las herramientas que necesitas para llevar tus aplicaciones a Linux rápido. El excelente compilador optimizado de Kylix está integrado sin rupturas para producir aplicaciones de alto rendimiento a alta velocidad. La reutilización y personalización de Kylix en sus extensas matrices de características y funcionalidades para web, escritorio y bases de datos, acelera tus tiempos de puesta en el mercado y refina tus entornos de desarrollo. Kylix™ es el camino más rápido para distribuir aplicaciones Linux. Con el entorno de diseño visual de Kylix los programadores crearán sofisticadas aplicaciones Linux más rápido que con cualquier otra herramienta de desarrollo. Muévete desde el prototipo a la producción rápidamente con la combinación única de herramientas de diseño visual, compilador y depurador de código nativo, ajuste para desarrollo de aplicaciones de web, bases de datos y escritorio de Kylix.

58



Acelera tus desarrollos para el servidor web Apache. Los componentes NetCLX se combinan tecnologías de desarrollo de navegador, servidor y bases de datos para entregar rápidamente aplicaciones web escalables que soporten un gran número de usuarios y un gran volumen de datos. El carril rápido para el desarrollo Internet. Integra fácilmente funciones Internet como son http, FTP, SMTP, y NNTP dentro de tus aplicaciones con Nevrona, el conjunto de componentes para Internet de Indy. Este conjunto mejorado viene con unos 65 componentes listos para utilizar que soportan los protocolos estándar para Internet. Conéctate fácilmente a tus bases de datos corporativas. Integra la información corporativa dentro de tus aplicaciones fácilmente con los drivers de alta velocidad dbExpress para Oracle, DB2, InterbBase, y MySQL. Haz rápidamente el prototipo de tu aplicación centrada en datos utilizando el rico conjunto de componentes GUI de datos de Kylix. Optimiza el rendimiento y la respuesta de tus aplicaciones de bases de datos con los componentes de comprobación y depuración de SQL Monitor. Incrementa la respuesta del servidor con las actualizaciones del Caché. Aplicaciones de alto rendimiento. Utiliza el compilador de código nativo altamente optimizado de Kylix para crear aplicaciones que se ajusten con la velocidad del relámpago. Crea y utiliza dinámicamente paquetes cargados para una máxima eficiencia de la aplicación y para fácilmente crear librerías de objetos compartidos reutilizables (.so's) y ejecutables independientes libres de royalty. Explota la potencia del desarrollo basado en componentes con CLX™. La librería de componentes para desarrollo en plataformas cruzadas (CLX) proporciona una paleta mejorada de unos 165 componentes reutilizables, personalizables y extensibles para construir rápidamente aplicaciones de los tipos Internet, bases de datos, y GUI. Utiliza el código fuente de los CLX para construir rápidamente tus propias componentes personalizados o reutilizar y extender fácilmente los componentes base para acelerar aún más tu velocidad de desarrollo. Desarrollo Delphi™ para Linux. Como desarrollador Delphi, tomarás la cabeza en los desarrollos para Linux con Kylix. Utiliza la misma forma de "arrastrar y colocar" visual de un entorno que te es familiar. Kylix incluye el mismo conjunto de herramientas incluyendo el Diseñador de Formularios, el Inspector de Objetos, depurador y compilador, además de CLX, la nueva librería de componentes de Kylix modelada siguiendo las VCL de Delphi para que las aplicaciones construidas in Delphi sean portadas fácilmente a Linux con mínimos cambios. Combina Kylix con Delphi para utilizar un solo conjunto de conocimientos experimentados y una sóla base de código para desarrollar aplicaciones para plataforma cruzada Linux/Windows. Construye aplicaciones fiables. Con Kylix, encontrar y arreglar errores incluso en el más complejo proyecto, nunca ha sido más simple. El depurador avanzado de Kylix está repleto de características que te ayudan a comprender y controlar las funciones tu código, incluyendo: Puntos de

58



ruptura para controlar el proceso de depuración, Inspector de Depuración de Kylix para monitorizar las propiedades de los componentes, un Log de eventos para mostrar los mensajes de control de procesos y las salidas del depurador y mucho más. Toma el control del desarrollo y distribución de grandes proyectos. Codifica fácilmente, depura y organiza las mayores aplicaciones con muchos ficheros fuentes interdependientes. El Advanced Multi-Target Project Manager (gestor de proyectos multi-objetos avanzado) simplifica el control de contenidos, la configuración del compilador, y la construcción de pedidos de cada módulo de tu proyecto. Fácilmente monitoriza las propiedades de los componentes con el Debug Inspector (inspector de depuración), navega por tu código con el Code Explorer (explorador de código), y salta instantáneamente al código fuente que necesitas con Hyperlinks y History Lists. MyBase™ base de datos personal XML. MyBase es un motor de base de datos local XML de mínima huella para un rápido rendimiento de tablas "en memoria", intercambio flexible de datos, de simple instalación sin configuración, y distribución. MyBase ofrece escalabilidad y migraciones transparentes para la aplicación a y desde cualquier RDBMS soportado por Kylix. MyBase soporta relaciones de tablas enlazadas maestro / detalle, todos los tipos populares de datos incluyendo Blobs, sintaxis ANSI 92 SQL para filtros, agregaciones en vivo, y constricción de datos, - todo para potentes RDBMS SQL- así como capacidades de base de datos local con los rápidos, fáciles de usar y de distribuir formatos de tablas XML. Distribución de aplicaciones libres de royalties. Las aplicaciones creadas utilizando Kylix están libres de cualquier coste de royalties de runtimes y corren sobre las mínimas configuraciones basadas en sistemas Linux. Los pequeños y robustos ficheros ejecutables generados por Kylix proporcionan la más rápida y eficiente solución Linux. Ahorra tiempo y reduce errores con CodeInsight. Con el CodeInsight de Kylix ahorrarás un tiempo de desarrollo notable y crearás código libre de errores. Utiliza las plantillas de código para personalizar la creación de macros. Automáticamente muestra el código de las propiedades del objeto disponibles, métodos, y fecha. El asistente de parámetros de código (Code Parameter Wizard), automáticamente muestra procedimientos, métodos y parámetros de eventos sugeridos. Construya el perfecto sistema llave en mano con InterBase. Con Kylix e InterBase, los desarrollos de alta productividad y alto rendimiento se combinan con una base de datos rápida y de bajo mantenimiento, y un mínimo de huella. InterBase es la base de datos de calidad comercial de código abierto, que combina la facilidad de uso con un bajo coste de mantenimiento y potencia empresarial. Con InterBase, VARs, Sis e ISVs rápidamente entregarán y distribuirán sistemas de alto rendimiento. Requerimientos Mínimos de Sistema:

• Intel® Pentium® 200 MHz (P2 400 MHz recomendado)

58



• 64 MB RAM (128 MB RAM recomendado) • CD-ROM • 175 MB espacio de disco duro para instalación completa • Monitor VGA o de mayor resolución • Ratón u otro puntero

Distribuciones de Linux Soportadas:

• Red Hat™ 6.2 o superior • Mandrake™ 7.2 o superior • SuSE® 7.0 o superior

Diferencias entre versiones: Aplicaciones nativas de Linux de altas prestaciones

Desktop Server Compilador de código nativo, optimización, altas prestaciones X X Librerías de objetos (.so's) fáciles de crear, libres de royalty e independientes de los ejecutables X X Use y cree paquetes de carga dinámicos para aumentar las prestaciones de su aplicación X X Ensamblador en línea con soporte completo para el conjunto de instrucciones de Intel x86, MMX, SIMD y AMD 3D NOW! X X Borland RAD Ambiente de desarrollo integrado (IDE) IDE con Editor de código integrado, depurador trazador, mensajes de error fáciles de entender y color resaltado para la sintaxis X X Múltiples perfiles del IDE permite un control total del entorno de desarrollo X X Code Explorer permite mapear código fuente dentro de su código desde un visualizador de proyectos X X Módulos de datos para aplicaciones no visuales, objetos y contenedores lógicos X X Listas ToDo para mantener su cronograma de desarrollo X X Administrador de proyectos avanzado X X Depuración avanzada integrada Depurador completo con resaltado de color en sintaxis X X Herramienta de evaluación de expresiones X X Depuración de .so para un control completo y fácil de la depuración X X Depuración de procesos en tiempo de desarrollo y en ejecución X X Visualizador de módulos y variables locales X X Visualizador del código de la CPU para depurar a bajo nivel X X Puntos de ruptura para vigilancia de datos X X Puntos de ruptura para una navegación más rápida X X Acciones de puntos de ruptura para incrementar el control sobre el proceso de depuración X X Grupos de puntos de ruptura para incrementar el control sobre múltiples puntos de ruptura X X Componentes Adicionales

58



Suite de componentes de protocolo Internet Indy de Nevrona: HTTP, FTP, SMTP, ICMP, UDP, MIME, Telnet, POP3, NNTP y más X X Código reutilizable con CLX: La librería de componentes para desarrollo en plataformas cruzadas Componentes estándar para desarrollo rápido de Aplicaciones 130+ 165+ Componentes visuales VisualCLX: Form, Label, Grid, Image, Bevel, ListBox y más X X Componentes de entrada VisualCLX: Menu, Button, Chekbox, RadioButton y más X X Componentes de control VisualCLX: Toolbar, Scrollbar, ControlBar, Splitter y más X X Diálogos comunes: Open, Save, Font, ColorPicker, Find y Replace X X Código fuente CLX para referenciar internamente a los componentes X X Conexión fácil a todos los datos corporativos con arquitectura abierta y extensible dbExpress, driver de altas prestaciones para permitir el acceso a cualquier motor de base de datos X X Rico conjunto de componentes orientados a datos para construir poderosas aplicaciones de base de datos X X Base de datos MyBase personal XML X X Drivers nativos dbExpress para MySQL e Interbase X X Drivers nativos dbExpress SQL para Oracle y DB2 X Componente SQL Monitor para probar, depurar y afinar aplicaciones SQL para su óptimo funcionamiento X X Transacciones avanzadas de cara a la aplicación para optimizar la conectividad con el servidor X X Soporte para operaciones Maestro/Detalle X X Cartera de datos XML para conectividad transparente con móviles y dispositivos de banda-ancha X X NetCLX: Marco de aplicaciones Web Apache NetCLX el marco de las aplicaciones Web Apache de alta velocidad, con alto rendimiento en la gestión de datos vía Web X Soporte de Apache para aplicaciones basadas en CGI y DSO X WebModules para Apache para centralizar la publicación de información con aplicaciones vivas en Internet X Asistente para comenzar a crear aplicaciones Web Apache rápidamente X Componentes para facilitar la comunicación vía Internet X Qué ha dicho la prensa. "La forma del mundo de desarrollo Linux cambiará dramáticamente con la versión de Kylix de Borland. Esto no es otro entorno "yo, también" que también abandona al usuario con largas y tediosas tareas para hacer a mano. Esto es un RAD completo, aquello con lo que los principales desarrolladores de Linux nunca han soñado. Lo mejor de todo, Kylix no es sólo una cara bonita; utiliza lo más profundo de Borland, el mejor creador de tecnología de compilación que está en uso desde mucho antes de que existiera Linux." - Lou Grinzo, Editor, LinuxProgramming.com

58



Dónde Adquirirlo. Puede obtener su Kylix a finales de febrero, con promociones especiales muy interesantes (descuento especial a usuarios Borland, regalo de libros, etc...) en Danysoft Internacional: 902.123146 – www.danyshop.com.

byte – suplemento especial 71: guía de borland para linux ...• aplicaciones de escritorio. •...

Documents