Aplicaciones Web con Cocoon y
PL/SQL
Centro de Tecnologas de la Informacin
Universidad de las Islas Baleares
Josep A. Frau
Domingo Sebastin
Resumen
En esta ponencia se describen los elementos fundamentales de Cocoon, as como las
extensiones realizadas en el CTI@UIB para convertirlo en la base de un entorno
productivo e integrado con los recursos ofrecidos por Oracle.
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
Aplicaciones Web con Cocoon y PL/SQL
Parte I Cocoon
La primera parte del documento muestra qu es Cocoon y porque fue la herramienta
elegida para construir las aplicaciones Web sobre Oracle.
Origen
Las necesidades que llevaron a escoger la arquitectura presentada se derivan de la
evolucin histrica de las aplicaciones desarrolladas en el CTI. Tradicionalmente, todos
los aplicativos de gestin interna se desarrollaban utilizando Forms Server de Oracle.
Con la llegada de Internet, nuevos requerimientos exigieron hacer accesibles
aplicaciones existentes a usuarios que llegaban a travs de la Web.
Las nuevas aplicaciones compartan parte del cdigo base con las ya existentes y
adems, la mayor parte del personal del CTI acumulaba un conocimiento y experiencia
en el desarrollo con herramientas de Oracle del que no se quera prescindir.
Durante los aos anteriores el CTI haba desarrollado una metodologa propia que
permita el desarrollo directo con la herramienta de anlisis de Oracle (Oracle
Designer). El trabajo previo de adaptacin de las preferencias para la generacin a partir
del anlisis fue un xito. El tiempo invertido fue sobradamente recuperado cuando,
posteriormente, se dispuso de la posibilidad de construir las aplicaciones directamente
desde las herramientas de anlisis y diseo con una productividad muy elevada.
En este contexto, no resultaba atractiva la idea de saltar a un entorno Web con
herramientas y lenguajes completamente nuevos. Se impona ms bien una adaptacin a
un entorno bien establecido que permitiese continuar con la solucin que tan buenos
resultados estaba dando.
Requerimientos
Por ello, el CTI elaboro una lista de requerimientos que reflejasen correctamente sus
necesidades. Se tomo muy en consideracin la situacin actual, sin dejarse llevar por
modas que, an siendo validas para otras organizaciones, no eran justificadas para el
caso actual.
El resultado final del estudio de requerimientos poda resumirse en la siguiente lista. La
nueva plataforma de desarrollo deba:
Reutilizar al mximo el cdigo disponible en PL/SQL.
Aprovechar al mximo los conocimientos en el entorno de desarrollo Oracle.
Usar tecnologas abiertas, basadas en estndares.
Usar tecnologas de fcil aprendizaje y productivas.
Con ello se pretenda una ampliacin al mundo Web de los desarrollos internos sin un
cambio traumtico que llevase a perder el modelo actual de trabajo.
La estrategia seguida para cumplir los requerimientos fue, en lnea con la teora bien
establecida, separar claramente los aspectos relacionados con la presentacin (donde
aplicaciones en Oracle Forms y aplicaciones Web diferiran notablemente) de los
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
aspectos relacionados con la lgica (donde habra muchas posibilidades de
reutilizacin).
A partir de este momento el trabajo fue analizar las distintas estrategias para la
separacin entre presentacin y lgica.
XML/XSLT
Entre las distintas opciones existentes se opt por usar la tecnologa XSLT (Extensible
Stylesheet Language Transformations) ya que cumpla con los requerimientos
establecidos y, adems, se mostraba slida y con una buena base de usuarios.
Con XSLT, el funcionamiento del sistema quedaba tal como se representa en la
siguiente figura:
HTML
Web Plantillas de
transformacin XSL
XML
PL/SQL Base de
datos
Aplicaciones
Oracle Forms
Con XSLT, los datos pueden representarse en XML, sin informacin de presentacin ni
ninguna dependencia a la tecnologa utilizada por el cliente. Con ello, se facilita la
reutilizacin de los datos y lgica de negocio y se aslan los aspectos de presentacin en
las plantillas de transformacin.
Cocoon
Cocoon es un framework para el desarrollo de aplicaciones Web modulares que asla los
distintos aspectos involucrados en la construccin y presentacin de las vistas. Para ello,
hace un intenso uso de las tecnologas basadas en XML.
La idea central de Cocoon es el proceso de las peticiones mediante un encadenamiento
de acciones independientes (pipelines) dirigidas de forma declarativa mediante un
fichero XML (sitemap) o de forma procedimental utilizando un lenguaje de script
(flowscript). Pipelines y flowscript no son tecnologas alternativas sino que se
complementan para implementar las distintas posibilidades de interaccin entre el
usuario y el sistema.
Durante la ejecucin de los pipelines o flowscript, pueden realizarse tareas de validacin
de datos, gestin de la sesin o muchas otras tareas tpicas, aunque la ms habitual es la
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
de convertir documentos nicamente con datos (XML) en vistas con la presentacin
deseada (HTML, PDF ) mediante hojas de estilo (XSL).
Modelo Vista Controlador
Veamos en ms detalle el esquema de funcionamiento del Cocoon.
El diseo de Cocoon response al patrn de diseo Modelo Vista Controlador
(MVC). El MVC distingue tres roles diferentes en los sistemas que interaccionan con un
usuario.
El modelo representa la lgica de negocio del sistema, independiente de la forma de
interaccin que tenga.
La vista la componen todos los elementos que son presentados al usuario: pantallas,
formularios, mensajes, etctera.
El controlador contiene la lgica que coordina el resto de componentes. Indica como
responder a cada accin del usuario, como utilizar el modelo, etctera.
En el caso de Cocoon, las vistas son generalmente las pginas HTML presentadas al
usuario, aunque pueden ser otros formatos como PDF o SVG. El modelo son
documentos XML, con datos sin informacin de presentacin.
Para el rol de controlador Cocoon proporciona dos tecnologas diferentes.
El [Link], es una forma declarativa de indicar como responder a cada peticin
recibida. A continuacin se presenta un ejemplo sencillo de sitemap:
<map:sitemap xmlns:map="[Link] >
<map:pipelines>
<map:pipeline>
<map:match pattern=[Link]>
<map:generate type=filesrc=[Link]/>
<map:transform type=xslt src=[Link]/>
<map:serialize type=html/>
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
Cocoon compara la peticin recibida (la URL) con los distintos patrones especificados
en los map:match. Una vez encontrado el match correspondiente, ejecuta la secuencia
de acciones (pipeline) declarada.
En el ejemplo anterior, para una peticin [Link] el resultado
devuelto ser la transformacin mediante [Link] del fichero [Link].
Con el sitemap disponemos de una forma limpia y escalable de describir el
comportamiento de la aplicacin, aunque a veces no es suficiente.
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
En las aplicaciones Web es frecuente que el flujo de navegacin no sea fcilmente
describible mediante una correspondencia peticin accin. Si la navegacin depende
del estado, es posible especificar la tarea del controlador de forma programtica.
El lenguaje utilizado para esta tarea, el flowscript, permite resolver de forma elegante
complejos esquemas de navegacin. El ejemplo que sigue captura dos entradas y
muestra una tercera pantalla en funcin de los valores entrados:
function comparacion ()
{
[Link] ([Link]);
var op1 = [Link](valor);
[Link] ([Link]);
var op2 = [Link](valor);
if (op1>op2)
[Link] ([Link]);
else
[Link] ([Link]);
}
A pesar de su sencillez conceptual, el flowscript es una potente herramienta a la hora de
resolver problemas asociados al mantenimiento del estado durante la navegacin del
cliente.
Por ejemplo, gestionar correctamente la informacin introducida por el cliente cuando
este retrocede algunos pasos durante un proceso complejo (el clsico problema del
botn back), se soluciona de forma natural sin apenas intervencin alguna del
programador.
Cocoon Forms
Cocoon Forms o CForms es la tecnologa de Cocoon para gestionar los formularios de
las aplicaciones Web. Cocoon presenta un modelo de formulario compuesto por cuatro
aspectos diferentes, descritos en ficheros independientes:
- La declaracin de los campos (Definition)
- En enlace de los datos con los campos (Binding)
- La plantilla de presentacin (Template)
- Los aspectos dinmicos de la aplicacin (Flowscript)
El form definition proporciona una definicin del formulario independiente de los datos
y de la presentacin:
<fd:form xmlns:fd="[Link]
<fd:widgets>
<fd:field id=op1" required="true>
<fd:label>Primer operador:</fd:label>
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
<fd:datatype base=integer"/>
<fd:validation>
<fd:range min=1 max=50"/>
</fd:validation>
</fd:field>
</fd:widgets>
</fd:form>
Cuando el formulario necesita recoger datos existentes se hace uso del Binding:
<fb:context xmlns:fb=[Link]
path="/" >
<fb:value id=op1" path=VALOR1"/>
</fb:context>
Sin entrar en detalles de su funcionamiento, en lnea general indica para cada elemento
del formulario, que elemento del documento XML proporciona sus datos.
Finalmente, se controla su presentacin mediante el fichero de Template.
<html>
<body>
<h1>Escoja dos nmeros</h1>
<ft:form-template
action={$continuation/id}.cont
method=post
xmlns:ft=[Link]
<ft:widget id=op1/>
<ft:action id=submit/>
</ft:form-template>
</body>
</html>
Problemas de Cocoon.
El principal problema de Cocoon es la documentacin. El framework no dispone de un
manual de referencia, ni una documentacin completa. La mayora de funcionalidades
deben extraerse del anlisis de los ejemplos proporcionados con el framework y en
demasiados casos consultando el cdigo directamente.
Irnicamente Cocoon naci como una herramienta para mejorar la Web y la
documentacin de los proyectos de la fundacin Apache, pero la documentacin de
usuario o desarrollador de Cocoon es muy mala, incompleta y muchas veces anticuada.
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
Esta debilidad es reconocida por la comunidad de desarrolladores de Cocoon y
peridicamente se proponen cambios en la infraestructura para generar la
documentacin. Pero faltan desarrolladores con conocimientos profundos de la
herramienta que la documenten de un modo completo, coherente y la mantengan
actualizada.
Parte II Pseudoprotocolo PL/SQL
En la parte anterior se han introducido las tecnologias escogidas como base de trabajo
para el desarrollo en el CTI. A continuacin se explica como la base anterior ha sido
extendida para hacer frente a los requerimientos expuestos.
Mecanismos de extensin del Cocoon
Cocoon es un producto construido con la intencin de ser fcilmente extensible. Cocoon
se forma a partir de un conjunto de elementos cuya integracin se especifica en un
fichero de configuracin llamado [Link]. Adems, las funcionalidades que
componen el Cocoon son descritas mediante interfaces.
Esto propicia que, en lugar de utilizar nicamente los elementos proporcionados por
Cocoon, podamos desarrollar nuestros propios componentes para despus, mediante la
modificacin del fichero [Link], integrarlos en nuestra distribucin de Cocoon
personalizada.
Interfaz 1
Componente_1
Cocoon
[Link]
Interfaz n
Componente_n
Son varios los aspectos que Cocoon permite personalizar y han servido para obtener la
funcionalidad requerida:
Source factories
Los Source Factories son componentes que permiten acceder a distintos tipos de
recursos.
Los ejemplos bsicos de Cocoon realizan transformaciones sobre contenido XML
guardado en ficheros pero, con otros source factories, podemos utilizar informacin
leda de bases de datos, de una URL, etc.
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
Generadores
Los generadores son los componentes que suministran el contenido original (una serie
de eventos SAX), a partir del cual se sucede la cadena de transformaciones hasta llegar
a la presentacin final.
Input-modules
Los input-modules permiten el acceso a los atributos de la peticin.
Funcionalidades del Pseudoprotocolo
CTI@UIB ha extendido ste framework bsico en distintas lneas buscando una mayor
productividad cuando la plataforma de desarrollo elegida es Oracle.
1. Desarrollar un protocolo de comunicacin directa entre Cocoon y
procedimientos PL/SQL.
2. Implementacin de un pool de conexiones integrado en Cocoon que permita, de
forma eficiente, cambiar el usuario de la conexin de un usuario genrico
asociado al pool, al cliente de la peticin. Se explicar como sta solucin
mejora la seguridad global del sistema y la reutilizacin del cdigo, sin
renunciar a los beneficios de escalabilidad y rendimiento ofrecidos por los pools
de conexiones.
3. Se proporciona una implementacin para validar los valores de los campos de un
formulario (CForms) contra procedimientos PL/SQL de la base de datos.
4. Se ha creado un sistema para guardar los valores de documentos XML,
especialmente construidos (tpicamente como resultado de un formulario
CForms) para ser tratados por procedimientos PL/SQL
Ejemplo de uso del Pseudoprotocolo
Antes de entrar en los detalles del funcionamiento del pseudoprotocolo, presentaremos
un simple ejemplo para facilitar posteriormente la comprensin de los detalles.
Desde el sitemap de Cocoon se configura una respuesta para la peticin [Link] con
la siguiente entrada:
<map:match pattern="[Link]">
<map:generate src="ora:plsql://POOL/[Link]?p1=COURE"/>
<map:transform src="xslt/[Link]" type="xslt"/>
<map:serialize type="html"/>
</map:match>
El sitemap indica que la respuesta se construir a partir del contenido (documento
XML) de la URL:
ora:plsql://POOL/[Link]?p1=COURE
procesado por la hoja de estilo xslt/[Link]
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
Veamos brevemente que sucede cuando Cocoon accede a la URL para obtener el
documento inicial.
En primer lugar analiza el nombre de protocolo para determinar que forma de acceso
utilizar. En el ejemplo, se trata del protocolo ora:plsql que previamente ha sido
registrado para usar las classes del pseudoprotocolo PL/SQL.
De este modo, la URL se pasa al pseudoprocolo para accedera a la fuente de XML.
El procesado de la URL extrae sus distintos componentes:
POOL es el nombre del pool de conexiones a utilizar
ejemplo es el nombre del package PL/SQL
proc es el nombre del procedimiento
p1 es un parmetro con valor CUORE
Por tanto, el resultado es la invocacin al procedimiento [Link] con parmetro
p1.
La implementacin de este procedimiento podra ser la que sigue:
PACKAGE BODY ejemplo IS
PROCEDURE proc (p1 IN VARCHAR2) IS
BEGIN
xmp.p( <SALIDA> );
xmp.p( LOWER (p1) );
xmp.p( </SALIDA> );
END proc;
END ejemplo;
El documento XML resultado del procedimiento es el acumulado en las sucesivas
invocaciones al procedimiento xmp.p. En nuestro caso seria:
<?xml version="1.0" encoding="iso-8859-1"?>
<SALIDA>
cuore
</SALIDA>
Este documento sera posteriormente procesado siguiendo los mecanismos estndares
de Cocoon.
Configuracin del pool de conexiones
Para acceder a la base de datos es necesario definir previamente uno o varios pools de
conexiones, a partir de los cuales se obtendrn las conexiones.
La configuracin se lleva a cabo en el fichero [Link], y es procesada por una
clase del pseudoprocolo que es la que crea el pool de conexiones.
<componentinstance
class="[Link]"
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
logger="[Link]"
name="ora">
<driver
ConnectionString="jdbc:oracle:thin:@[Link]:1539:SID"
PoolName="poolname"
User="usuario"
Password="password"
PoolType="CACHE_POOL">
<configuration
MaxConn="7"
MinConn="3"
Wait="FALSE"
TimeoutConn="2"
IncrementConn="1"/>
</driver>
</componentinstance>
En la configuracin se especifican:
- la cadena de conexin utilizada por el JDBC
- el nombre dado al pool
- el usuario y password para la conexin
- el tipo de pool
- el nmero mximo y mnimo de conexiones
- si esperar o no una para una conexin una vez sobrepasado el mximo
- tiempo mximo de inactividad antes de cerrar una conexin
- nmero de conexiones a crear simultneamente
Los tipos de pool existentes son:
- JDBC_POOL utiliza la API estndar de JDBC
- OCI_POOL utiliza la API especfica de los driver OCI. Permite, entre otras
funcionalidades, cambiar el usuario de las conexiones una vez obtenidas del
pool
- CACHE_POOL utiliza una implementacin de Oracle de pool de conexiones.
Usuarios y conexiones
A la hora de afrontar la implementacin del pseudoprotocolo PLSQL se tuvo que
afrontar otro problema relacionado con las distintas culturas o formar de entender la
aplicacin por parte del desarrollo tradicional de aplicaciones sobre bases de datos y las
aplicaciones Web.
Las aplicaciones Web, generalmente hacen uso de un nico usuario para el acceso a
base de datos. La existencia de un nico usuario, compartido por todos los clientes
permite disponer de las ventajas de un pool nico de conexiones y facilita la gestin del
servidor de aplicaciones.
El CTI@UIB, para sus aplicaciones basadas en Oracle Forms, haba desarrollado un
sistema de seguridad basado en los mecanismos de gestin y agrupacin de permisos
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
del gestor de base de datos Oracle. Esencialmente, el sistema asocia los usuarios y
perfiles a los objetos de la base de datos basndose en una definicin de las unidades
funcionalidades del sistema (mdulos de aplicaciones Web, Forms o Reports) y de los
permisos que stas requieren.
Por ese motivo, era necesario que los accesos a la base de datos desde la aplicacin Web
se realizasen con usuarios asociados al cliente y no con una conexin comn.
La solucin al problema vino de mano de la implementacin OCI de los drivers de
Oracle. Esta implementacin permita la re-autenticacin sobre una conexin creada con
un coste sustancialmente inferior al de crear una conexin nueva.
La arquitectura resultante, por tanto, consista en mantener un pool de conexiones con
un usuario genrico y, al obtener una conexin del pool, realizar una re-autenticacin
con el usuario asociado a la peticin.
El resultado final fue el acceso a los beneficios en trminos de seguridad
proporcionados por la infraestructura elaborada para las aplicaciones Forms,
conservando el rendimiento y facilidad de gestin tpico de los pools de conexiones de
las aplicaciones Web.
Tipos de URLs y funcionalidad
Forma bsica
La forma ms bsica de URL es la que invoca a un procedimiento sin parmetros ni
atenticacin:
ora:plsql://pool/[Link]
ora:plsql es el nombre dado al protocolo creado
pool es el nombre con el que se ha declarado el pool en el fichero [Link]
paquete es el nombre del package PLSQL
procedimiento es el nombre del procedure
Autenticacin
En el caso, ms habitual, de necesitar acceder a conexiones con usuario y password se
utiliza:
ora:plsql://usuari:password@pool/[Link]
Parmetros de entrada
ora:plsql://usuari:password@pool/[Link]?IN:arg1=val1&INarg2=val2
Opcionalmente, puede simplificarse la URL anterior eliminando IN:, ya que por
defecto, los parmetros son de entrada.
ora:plsql://pool/[Link]?arg1=val1&arg2=val2
Parametros de entrada y salida
Si un parmetro es de entrada/salida o salida, sustituimos IN por INOUT o OUT:
ora:plsql://pool/[Link]?IN:arg1=val1&INOUT:arg2=val
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
Parmetros mltiples
Hay dos maneras de pasar parmetros mltiples. Podemos pasar el parmetro repetido:
ora:plsql://pool/[Link]?arg1=val1&arg1=val2
O podemos utilizar otra notacin ms compacta:
ora:plsql://pool/[Link]?arg1=val1~val2
Variables de entorno
La notacin con URL tambin permite definir variables de entorno activas durante la
ejecucin del procedimiento:
ora:plsql://pool/[Link]?arg1=val1&#en1=val1&#en2=val2
Transacciones
Para trabajar con transacciones, debe utilizarse el flowscript, ya que la interaccin
necesaria con los pools no puede realizarse desde el sitemap.
Si necesitamos que distintas invocaciones formen parte de una misma transaccin,
entonces el procedimiento es el siguiente:
En primer lugar iniciamos y obtenemos la transaccin.
String transid = [Link] ( pool, user, password);
Posteriormente la usamos en distintas invocaciones:
ora:plsql://pool-transid/[Link]
Podemos finalizar la transaccin con
[Link]( transid, user, password );
o
[Link]( transid, user, password );
Extensiones al CForms
El mecanismo bsico de validaciones en formularios ha sido extendido con nueva
funcionalidad que permite acceder a lgica de negocio en PL/SQL.
Algunas aplicaciones existentes, realizaban complejos procesos de validacin de los
datos de usuario utilizando informacin de la base de datos. Estos procesos estaban
implementados en PL/SQL y estaban integrados en un mecanismo de elaboracin propia
para el tratamiento de errores.
Con la intencin de evitar la duplicacin de cdigo, se analizaron distintas estrategias
para usar este cdigo directamente en las aplicaciones Web.
Finalmente, la opcin que se considero ms adecuada, fue la de extender el CForms de
Cocoon para poder delegar la validacin de uno o varios campos a un procedimiento
PL/SQL.
Se valor el hecho que los procedimientos existentes podan reutilizarse sin
modificacin y que la gestin del error quedaba en manos de CForms, con lo que se
garantizaba una presentacin consistente con el resto de la capa Web.
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
<fd:plsql
Procedure="ora:plsql://POOL/[Link]"
WidgetError="pathalwidgetquerepresentarelerror">
<fd:parametreNom="parametro1"
WidgetPath="pathaunwidgetconelvalor"/>
<fd:parametreNom="parametro2"Valor="Valorconstante"/>
</fd:plsql>
El cdigo anterior instruye al gestor de formularios de Cocoon para que invoque a un
determinado procedimiento para realizar la validacin, con los dos parmetros
especificados: uno con el valor recogido en uno de los campos y el segundo con un
valor constante.
En caso de que la validacin produzca un error el formulario es advertido de la situacin
y se le proporciona el mensaje descriptivo devuelto por el procedimiento PL/SQL
Aplicaciones implementadas con el Pseudoprotocolo PL/SQL
El CTI@UIB ha experimentado con Cocoon desde la versin 1.x. Cuando bsicamente
era un servlet para transformar documentos XML utilizando XSLT. Aunque las
aplicaciones Web en produccin se desarrollaban usando un framework propio
(WebLeaf).
El primer proyecto en usar Cocoon fue el Web del CTI@UIB. Este proyecto de
publicacin Web, usaba las caractersticas de framework de publicacin que proporciona
el Cocoon. Se desarroll en el 2003 sobre la versin 2.1.3 de Cocoon. Como parte del
proyecto de publicacin del Web del SCI se cre una macro de Word para permitir la
confeccin de contenidos de un modo fcil para los usuarios. Estos escriban
documentos de Word que eran transformados en XML por la macro para ser publicado
en el Web. <[Link] Todos los contenidos del servidor se generan
dinmicamente en cada peticin al Web.
El primer proyecto en usar las caractersticas de framework de aplicaciones Web fue el
Herbario Virtual de las Islas Baleares <[Link] Para esta aplicacin
se desarroll el pseudoprotocolo PLSQL para interaccionar con la base de datos. Esta
aplicacin sirve para introducir la informacin de las especies vegetales de las islas
Baleares y con ella generar el Web que es accesible a los usuarios. Est desarrollado
sobre Cocoon 2.1.5. Las peticiones del usuario son generadas sobre un servidor Web
para reducir la carga sobre el servidor dinmico. Se desarrollo la primera versin de la
aplicacin durante el ao 2004.
El desarrollo del pseudoprotocolo PLSQL sirvi para actualizar el Web del CTI para
recoger dinmicamente informacin de noticias des de la base de datos y publicarlo en
el Web.
El proyecto actual es una aplicacin para la automatizacin de la Fundaci Universitat
Empresa de les Illes Balears. El primer mdulo Web que se ha desarrollado es el
mantenimiento del currculo por parte de los candidatos de la bolsa de trabajo de la
fundacin.
En este proyecto se ha utilizado Flowscript y CForms. Para este proyecto se han
desarrollado extensiones para CForms y funciones para acceder a procedimientos PLSQ
desde flowscript sobre el pseudoprotocolo PLSQL.
Cuore 2005 Josep A. Frau
Domingo Sebastin
Aplicaciones Web con Cocoon y PL/SQL CTI@UIB
Actualmente se est desarrollando una nueva versin del Web del CTI sobre Lenya (un
proyecto de CMS sobre Cocoon).
Posibles evoluciones
Aprovechando la funcionalidad que aporta CForms en la gestin de formularios Web se
han previsto algunas mejoras en la metodologa.
Oracle Designer permite almacenar informacin de los campos de las tablas como
longitud mxima, longitud de presentacin, label, hint, listas de valores, etc. esta
informacin podra utilizarse para definir el documento de definicin de los formularios.
De la informacin de los mdulos almacenada en Designer se podra generar un
prototipo de los formularios Web creando los documentos de binding.
Para los mantenimientos sencillos se podra utilizar una herramienta de mapeo como
Hibernate y utilizar como fuente del proceso de binding Java Beans generados por la
herramienta de mapeo.
Conclusiones
El sistema construido se ha mostrado productivo, simple y de aprendizaje fcil. La
separacin conseguida entre la capa de presentacin y la de negocio permite aprovechar
cdigo y conocimientos en Oracle ya existentes. El acceso a los procedimientos
almacenados mediante simples URLs y el tratamiento posterior del resultado mediante
plantillas de transformacin XSL es suficientemente sencillo para construir aplicaciones
Web con una productividad comparable a las aplicaciones Form Server.
Cuore 2005 Josep A. Frau
Domingo Sebastin