Un complemento del IBM Mashup Center para realizar transformaciones XSLT

Presentación de la API del complemento de Mashup Center v2.0

Aprenda cómo construir un complemento XSLT para la Versión 2 del IBM®Mashup Center que aprovecha el soporte incorporado para la autenticación Basic y basada en formularios.

Louis Mau, Solution Architect, IBM

Louis Mau forma parte del equipo de desarrollo de InfoSphere MashupHub. Actualmente se ocupa de ayudar a los clientes a construir aplicaciones situacionales con IBM Mashup Center. Antes de este rol, fue el Architect de DB2 Everyplace Sync Server.



04-03-2009

Introducción

IBM Mashup Center viene con un editor de mashups de datos que usted puede usar para combinar y transformar XML de fuentes múltiples. El editor de mashups de datos es fácil de usar, pero en algunos escenarios, quizás usted descubra que resulta más eficiente el uso de XSLT para realizar sus transformaciones de XML. Para que usted pueda aprender cómo beneficiarse de ambos tipos de transformaciones, este artículo le muestra cómo construir un complemento del IBM Mashup Center que pueda realizar las transformaciones XSLT.

"Amplíe el alcance de los datos para el IBM Mashup Center" y "Un complemento de IBM Mashup Center para convertir HTML en XML" son dos artículos de developerWorks anteriores que describen el modo de desarrollar complementos para ampliar las capacidades de IBM Mashup Center (consulte la sección Recursos para ver los vínculos correspondientes). Esos artículos se basan en la versión 1 del Mashup Center. El énfasis de este artículo está puesto en las nuevas capacidades de la versión 2 de la API del complemento, como por ejemplo el soporte a la autenticación Basic y basada en formularios. Sólo se ocupa de las áreas donde existen diferencias significativas respecto de las versiones 1 y 2 de la API del complemento..

Este artículo presupone que usted ya se encuentra familiarizado con los principios básicos de la programación de un complemento para IBM Mashup Center. En particular, usted deberá saber cómo programar en Java™, JSP, JavaScript, y XSLT.

Breve resumen de los cambios realizados a la API del complemento de la v2.0

Es probable que distintos complementos requieran diferentes versiones del mismo paquete Java. Para poder ofrecer la aislación necesaria, a partir de la Versión 2, las clases de cada uno de los complementos se cargan con diferentes cargadores de clases. Las clases y los jars específicos del complemento se guardan dentro de una carpeta específica para el complemento y no se copian en una ubicación común, como sucedía en la Versión 1. La interacción con el framework se realiza ahora principalmente por medio de interfaces, en lugar de clases concretas. Por ejemplo, el método renderEditor de la Versión 1 solía tomar como parámetros a dos clases concretas: RequestData (Solicitar datos) y Entry (Entrada). Pero en v2.0, las instancias clases cambian por interfaces, como se muestra en el Listado 1.

Listado 1. Uso de una interfaz como parámetro
// v1.1 public ViewBean
                renderEditor(RequestData rdata, Entry entry) public Object
                renderEditor(IEditorContext context)

Los cambios anteriores no tienen un efecto significativo sobre la implementación del complemento. Donde los cambios de la v2.0 resultan más notables es en la implementación de las JSP del complemento. Debido a que las JSP son cargadas por el cargador de clases de JSP del Web Container, las mismas no pueden acceder a las clases específicas del complemento (ViewBean). En lugar de usar captadores específicos del atributo, la JSP de complemento de la v2.0 debe usar nombre genérico / pares de valores para recuperar los atributos, lo cual se demuestra en una sección posterior.


Configuración de un proyecto de Eclipse

Como se describe en la Sección 6.1 de la Application Programming Interface Reference, Versión 2.0 (consulte Recursos para ver el vínculo), durante el inicio, el servidor busca archivos ZIP que contengan complementos de terceros que se hayan colocado en la carpeta especial <WebApplication>/WEB-INF/plugins. El archivo ZIP debe tener la siguiente estructura de carpeta:

  • /client/plugins/PLUGIN_DIR — Contiene archivos para buscadores, como por ejemplo, imágenes y archivos JavaScript.
  • /server/plugins/PLUGIN_DIR — Contiene el manifiesto del complemento y los archivos usados por el complemento para convertirse a sí (páginas JSP).
  • /server/plugins/PLUGIN_DIR/classes — Contiene las clases Java del complemento. Puede ser una jerarquía de carpetas.
  • /server/plugins/PLUGIN_DIR/lib — Contiene los archivos JAR usados por el complemento (terceros).

Si usted está familiarizado con el desarrollo de complementos para la v1.1, quizás note que las clases y carpetas lib ya no se encuentran dentro de la carpeta WEB-INF. Con el fin de simplificar la construcción final y el armado de paquetes del complemento, use su IDE preferida para crear un proyecto que tenga la misma estructura de directorio que requiere el archivo ZIP final. La Figura 1 muestra la organización de un proyecto Eclipse de muestra.

Figura 1. Proyecto Eclipse
Screen shot of the hierarchical structure of a sample Eclipse project following the ZIP file structure described above.

Usted puede encontrar la totalidad del proyecto Eclipse de muestra en la sección Descarga.El ejemplo usa el nombre de paquete sample.mashupcenter.xslt para PLUGIN_DIR. Además, contiene una carpeta adicional denominada lib_noship que aloja el archivo mhubapi.jar de la Versión 2 del IBM Mashup Center que usted necesitará durante el desarrollo. Usted dispone de una copia del archivo mhubapi.jar en la carpeta <installationDir>\Hub\installedApps\Mashup Hub.ear\mashuphub-enterprise.war\client\api de su servidor. Usted solo necesita este archivo durante el desarrollo; después deberá eliminarlo del archivo ZIP para la implantación final.

El Listado 2 muestra los contenidos del plugin.xml nombrado para el archive que se encuentra en la carpeta server/plugins/PLUGIN_DIR.

Listado 2. Archivo XML del paquete
<?mhub version="2.0"?> <plugin>
<name>XSLT Transform</name>
<description>Apply XSLT to transform XML</description>
<author>IBM</author>
<version>2.0</version> <extension
id="sample.mashupcenter.xslt.transformeditor" name="XSLT Transform Editor"
point="com.ibm.mashuphub.core.extension.IEditor"> <editor
class="sample.mashupcenter.xslt.TransformEditorPlugin" type="xslt"
category="departmental"
icon="/plugins/sample.mashupcenter.xslt/icons/btn16_hello.gif" name="%editor.name"
description="%editor.description" /> </extension>
<extension id="sample.mashupcenter.xslt.transformgenerator" name="XSLT
Transform Generator" point="com.ibm.mashuphub.core.extension.IGenerator">
<generator class="sample.mashupcenter.xslt.TransformGeneratorPlugin"
type="xslt" /> </extension> </plugin>

Además de proporcionar la información básica sobre el complemento, el archivo plugin.xml contiene nombres de las clases que implementan el componente Editor y Generator. De manera predeterminada, el complemento genera feeds y el nombre del Editor se presenta en una lista donde los usuarios deben seleccionar Create (Crear) y luego New Feed (Nuevo feed), como se muestra en la Figura 2.Observe, además, que el nombre del Editor aparece bajo departmental, que es la categoría especificada en el archivo.xml del complemento.

Figura 2. Cómo cargar la casilla del listado de selección del complemento
Screenshot of the Mashup Center feed plug-in selection listbox with the new XSLT Transform selected.

Para permitir la internacionalización, usted deberá especificar variables para los parámetros name (nombre) y description (descripción). Por ejemplo, en el ejemplo de plugin.xml que se muestra en el Listado 2, %editor.name y %editor.description son variables. Sus valores están especificados en un archivo denominado plugin.properties que se ubica en el mismo directorio que plugin.xml. El archivo plugin.properties es cargado por el framework usando la convención estándar para carga de paquetes de recursos Java. Para cada uno de los idiomas soportados, ubique las cadenas traducidas en un archivo de propiedades con el locale anexado a "plugin". Por ejemplo, la versión japonesa del archivo deberá llamarse plugin_ja.properties.


Implementación del editor

Como se especifica en el archivo plugin.xml file, la clase TransformEditorPlugin brinda la function de edición del complemento. Su implementación amplía BaseEditor, una clase de base que requiere la implementación del método renderEditor. El método renderEditor es llamado por el framework cuando los usuarios seleccionan crear un nuevo feed con este complemento, o cuando los usuarios editan un feed existente creado previamente por este complemento.

Listado 3. Clase TransformEditorPlugin
public class
TransformEditorPlugin extends BaseEditor { @Override public Object
renderEditor(IEditorContext context) { ResourceBundle i18n =
ResourceBundle.getBundle(TransformConstants.I18N_RESFILE, context.getLocale());
IEntry entry = context.currentEntry(); ILog log = context.getLog(); IRequestContext
request = context.getRequestContext();

El método renderEditor de la Versión 2 toma un único parámetro: IEditorContext. El parámetro es común a todos los métodos invocados por el framework como respuesta a las acciones de edición del usuario. Recuerde la última discusión sobre el uso de interfaces o clases concretas. De este contexto, usted obtiene la interfaz IRequestContext que contiene la información enviada desde el navegador, y IEntry que contiene toda la información que guardada por el framework para esta instancia de feed. El uso de estas interfaces es similar al uso de las clases RequestData y Entry en la Versión 1, de manera que este artículo no ofrece información adicional sobre este tema. Sin embargo, si usted desea más detalles al respecto, podrá consultar los dos artículos sobre la Versión 1 mencionados anteriormente, cuyos vínculos se incluyen en la sección Recursos.Usted podrá encontrar el Javadoc para la API del complemento en su instalación de IBM Mashup Center si se dirige al siguiente URL: http://<yourserver>/mashuphub/client/doc/javadoc/index.html.

Observe también que la instancia de inicio de sesión ahora pasa y es accesible a través del parámetro IEditorContext. Los mensajes de registro se intercalan con los del framework de generación de feeds y se escriben en el siguiente archivo: <WebApplication>/META-INF/logs/javamashuphub.log. De manera predeterminada, solamente los mensajes con una gravedad WARN (advertencia) o superior (por ejemplo, ERROR) se escriben en el archivo de registro.

El Listado 4 muestra el cuerpo del método renderEditor.

Listado 4. Cuerpo del método renderEditor
BasicEditorViewBean
htViewBean = new BasicEditorViewBean( TransformConstants.JSPPATH_TRANSFORM );
htViewBean.setEntry(entry); htViewBean.setI18NProperties(
TransformConstants.I18N_RESFILE ); String s =
entry.getAttribute(TransformConstants.PARAM_XSLT ); htViewBean.addAttribute(
TransformConstants.PARAM_XSLT , escapeXml( s ) ); IParameter param =
entry.getParameter( TransformConstants.PARAM_XMLURL ); if ( param != null ) {
htViewBean.addAttribute( TransformConstants.PARAM_XMLURL , param.getDefaultValue()
); } AuthHelper helper = AuthHelper.restoreFromEntry(context ,
AuthConstants.AUTH_METHOD_BASIC , null ); ViewBean authViewBean =
helper.getViewBean(context); FormViewBean form = new FormViewBean(); form.setSuffix(
SUFFIX_TRANSFORM ); form.addComponent( htViewBean ); form.addComponent( authViewBean
); form.setOnsubmit( PluginHelper.getClientMe(pluginId, entry.getObjectId()) +
".invokeServer('displayPreviewPage'," + PluginHelper.getClientId(pluginId,
entry.getObjectId()) + "_" + form.getSuffix() + ");");

El método renderEditor devuelve una instancia del tipo ViewBean. El propósito principal de ViewBean es especificar la JSP utilizada por el framework de generación de feeds para crear un fragmento HTML para el editor específico del complemento. En la Versión 2, las JSP son cargadas por el cargador de clases JSP del Web Container, y no pueden acceder a las clases específicas del complemento, como por ejemplo, ViewBean. De manera que en lugar de crear una clase ViewBean específica para el complemento, la muestra anterior usa la clase genérica BasicEditorViewBean que brinda el framework. La ruta a la JSP específica del complemento pasa a través del constructor. Los parámetros específicos del complemento pasan a la instancia BasicEditorViewBean a través del método genérico addAttribute en lugar de usar captadores y establecedores de parámetros específicos. Estos parámetros específicos del complemento se usan para completar previamente el formulario de edición con los valores que el usuario ingresara en anteriores sesiones de edición.

Como se explicara en uno de los artículos anteriores, la ViewBean específica del parámetro no se devuelve directamente al framework. En cambio, se agrega al FormViewBean. Este último contiene la lógica para interactuar con el framework y brindar una experiencia de edición de múltiples pasos similar a la de un asistente. La diferencia radica a que este ejemplo agrega dos ViewBeans al FormViewBean. El FormViewBean puede armar pieza por pieza los múltiples fragmentos de HTML generados por las JSP y asociados con múltiples ViewBeans.

La Figura 3 muestra el formulario que se genera a partir de las dos ViewBeans.

Figura 3. Editor del complemento de la XSLT
Screenshot of a form with two required fields (XSLT and Test URL) and a check box that specifies if authentication is required.

Los principales dos elementos son un área de texto para ingresar la XSLT y un campo de entrada de texto para el URL que señala el XML que se deberá transformar. Estos elementos son generados por la JSP específica del complemento. Usted puede encontrar la JSP específica del complemento en el archivo XSLTPlugin.zip que se encuentra disponible en la sección Dscarga. Las JSP y el framework JavaScript del lado del cliente no cambian demasiado entre las versiones 1 y 2, por lo que usted deberá consultar el artículo anterior para ver detalles sobre estos temas.

La segunda ViewBean es devuelta por la clase AuthHelper al llamar al método restoreFromEntry. La clase AuthHelper se agrega en la Versión 2 para facilitar el agregado de soporte a las autenticaciones Basic y basada en formularios de cualquier complemento de terceros. La ViewBean AuthHelper genera todos los elementos de formulario necesarios para reunir credenciales para los métodos de autenticación soportados. Posteriormente en este artículo, usted aprenderá a usar las credenciales reunidas para acceder al URL que contiene los datos a transformar.

La Figura 4 muestra los elementos de formulario generados cuando se selecciona la autenticación Basic.

Figura 4. Formulario de autenticación
Screenshot of authentication form with Basic selected as type of authentication.

Antes de abandonar este tema, observe que la instancia AuthHelper se crea llamando al método estático restoreFromEntry y que el primer parámetro es la instancia IEditorContext. AuthHelper usa la instancia IEditorContext para recuperar automáticamente los valores de parámetros guardados con el feed en una invocación previa del editor. ¡El que llama no tiene que hacer nada!


MétododisplayPreviewPage

El diseño de este ejemplo de complemento es similar al del complemento que se describe en el artículo "Un complemento del IBM Mashup Center para convertir HTML en XML" (ver Recursos). Los usuarios pegan el XSLT en el casillero de texto, proporcionan un URL de prueba, y luego proceden a la página de vista previa oprimiendo el botón Next (Siguiente). El método para ayudar a generar la página de vista previa que sigue se encuentra especificado en el método anterior renderEditor, donde hemos insertado una pequeña porción de código Javascript usando form.setOnsubmit como se muestra en el Listado 4. Usted puede recuperar el archivo JavaScript que brinda la API del lado del cliente en este URL: https://<yourserver>/mashuphub/client/scripts/hub/managers/Plugin.js El JavaScript insertado invokeServer llamará al método específico displayPreviewPage a través de una llamada AJAX.

El Listado 5 muestra el cuerpo del método displayPreviewPage.

Listado 5. Cuerpo del método displayPreviewPage
entry.addAttribute(TransformConstants.PARAM_XSLT
, sXSLT ); IParameter eparam = entry.createParameter(); eparam.setName(
TransformConstants.PARAM_XMLURL ); eparam.setDefaultValue( sUrl );
eparam.setType("string"); eparam.setPrompt("Y"); entry.addParameter( eparam );
AuthHelper authHelper = AuthHelper.createFromRequest( context ,
AuthConstants.AUTH_METHOD_BASIC , null ); authHelper.saveParameters(context);
authHelper.saveCredential( context );

El principal propósito del método displayPreviewPage es devolver una segunda ViewBean (en consecuencia, JSP) al marco para que proporcione una página de editor que muestre el resultado de la transformación XSLT. Antes de devolver el resultado de la transformación XSLT, el método deberá primero guardar los parámetros suministrados por el usuario. El código del Listado 5 muestra de qué manera se guardan las distintas informaciones. XSLT se deberá usar en cada generación de feed, para que se pueda guardar como atributo. El XML a transformar puede variar según la invocación, de manera que se guarda como un parámetro. Observe que la Versión 2 posee un nuevo método denominado createParameter que se usa para devolver una instancia de la interfaz del parámetro. Para la información relacionada con la autenticación, el ejemplo otorga una nueva instancia de AuthHelperllamando al método estático createFromRequest. De esta manera se extrae y conserva toda la información de autenticación de la solicitud HTTP especificada por el usuario.

La vista previa de la transformación XSLT verdadera es algo común en la generación de feeds, y se trata a continuación. Con esto concluye la discusión sobre el Editor. Nuevamente, el código fuente completo está disponible en la sección Descarga.


Implementación de la generación de feeds

La clase TransformGeneratorPlugin amplía la clase BaseGenerator y debe implementar el método abstracto generateFeed. De manera similar a la del método renderEditor, toma un único parámetro, que es una instancia de la interfaz IGenerateContext. En la instancia IGeneratorContext, usted obtiene la instancia de la interfaz IRequestContext que contiene la información enviada desde el navegador, y una instancia IEntry que contiene toda la información que guarda el framework para esta instancia del feed.

El Listado 6 contiene el texto estándar para el método generateFeed.

Listado 6. Cuerpo del método renderEditor
public class
TransformGeneratorPlugin extends BaseGenerator { public IFeedContent
generateFeed(IGeneratorContext context) throws GeneratorException { ILog log =
context.getLog(); IEntry entry = context.currentEntry(); IRequestContext request =
context.getRequestContext(); ResourceBundle i18n = ResourceBundle.getBundle(
TransformConstants.I18N_RESFILE , context.getLocale());

Para poder generar feeds, en primer lugar usted debe recuperar los atributos que contienen la información de configuración guardada durante el proceso de edición; para este complemento es la XSLT ingresada en la casilla de texto durante la edición. Cada una de las invocaciones usa la misma XSLT. La XML a transformar puede variar según la invocación y se encuentra especificada en el parámetro URL de generación de feeds denominado xmlurl. Estas operaciones son bastante simples en comparación con las instancias IEntry y IRequestContext, por lo cual no se incluye en este artículo el fragmento de código relevante.

Después de recuperar el XML a transformar, la implementación de la transformación real resulta algo muy sencillo. Como se muestra en el Listado7, es bastante simple iniciar la transformación XSLT usando JAXP y el motor XSLT que se entrega con JDK.

Listado 7. Cuerpo del métodorenderEditor
TransformerFactory
tFactory = TransformerFactory.newInstance(); Transformer transformer =
tFactory.newTransformer(new StreamSource( rdrXSLT )); // Use the Transformer to
apply the XSLT to the XML document Writer writer = new StringWriter();
transformer.transform( new StreamSource( rdrContent ) , new StreamResult( writer ));
String after = writer.toString();

Lo que tiene interés en este ejemplo es la manera en que usted recupera el contenido del URL provisto por el que llama. En lugar de ejemplificar directamente una instancia java.net.URL, usted debe ejemplificar primero una instancia de AuthHelper para esta entrada de feed mediante el pase de contenidos. Entonces, obtiene una conexión desde la instancia AuthHelper mediante un llamado al método connect y pasando el URL. Bajo la cubierta, la instancia AuthHelper genera el handshake HTTP adecuado según el método de autenticación especificado y usando las credenciales provistas durante la creación del feed. Además, si el Mashup Center está configurado para usar un proxy, la solicitud es dirigida a través del proxy especificado. El Listado 8 muestra las dos líneas de código necesarias para esta tarea.

Listado 8. Cuerpo del método renderEditor
AuthHelper helper = AuthHelper.restoreFromEntry(
context , AuthConstants.AUTH_METHOD_BASIC , null ); conn = helper.connect(context,
sUrl);

Con esto concluye nuestra visita a la implementación. Ahora es el momento de ver al complemento en acción.


Utilización de la muestra

Esta sección le muestra cómo hacer uso del complemento. El primer ejemplo toma en cuenta un caso en el cual uno de los elementos del xml de entrada contiene una gran cantidad de atributos. La idea es convertirlos en elementos para que se puedan visualizar usando los widgets que vienen con el producto. Esta tarea resulta sencilla con el operador Transform del editor del mashup de datos. Para cada uno de los atributos, usted creará un elemento en la entrada para resultados y luego copiará el valor del atributo. Sin embargo, si la cantidad de atributos es alta, esto puede resultar algo tedioso. Una alternativa consiste en usar XSLT. A modo de ejemplo, observe el archive de muestra attributes.xml que se incluye en el XSLTPlugin.zip descarga y que se muestra en el Listado 9.

Listado 9. attribute.xml
<root> <entry> <info
                product='camera' price='40.00' instock='y'/> </entry>
                <entry> <info product='USB drive' price='60.00'
                instock='n'/> </entry> </root>

El Listado 10 es un fragmento del XSLT de muestra de attribute.xsl incluido en el XSLTPlugin.zip descarga. Esta es la porción que realiza la transformación de atributos a elementos. El elemento xsl:template se usa para ubicar el elemento de interés, que en este caso es info. Una vez encontrado, la construcción xsl:for-each repite el ciclo con todos los atributos seleccionados usando el patrón @*. para cada atributo correspondiente al patrón, la construcción xsl:element crea un elemento con el mismo nombre que el atributo. Por último, el valor texto del atributo se coloca dentro del elemento recientemente creado.

Listado 10. Fragmento de attribute.xsl
<xsl:template match="info">
                <info> <xsl:for-each select="@*"> <xsl:element
                name="{name()}"> <xsl:value-of select='.' />
                </xsl:element> </xsl:for-each> </info>
                </xsl:template>

El siguiente ejemplo explota las más ricas capacidades condicionales de XSLT para agregar una marca HTML que amplía la visualización de un feed usando el widget DataViewer que viene con el producto Mashup Center. El Listado 11 muestra el feed de muestra stocks.xml que también se incluye en el XSLTPlugin.zip descarga. El archivo se creó al cargar un archivo CSV que contiene citas de tiempos reales del sitio financiero de Yahoo!

Listado 11. stocks.xml
<entry xmlns="http://www.w3.org/2005/Atom">
                ......... <content type="application/xml"> <row
                xmlns="http://www.ibm.com/xmlns/atom/content/datarow/1.0">
                <col_A>BAC</col_A>
                <col_B>14.94</col_B>
                <col_C>11/6/2009</col_C>
                <col_D>11:23am</col_D>
                <col_E>-0.19</col_E>
                <col_F>14.94</col_F>
                <col_G>15.24</col_G>
                <col_H>14.84</col_H>
                <col_I>68841848</col_I> </row>
                </content> </entry>

En este caso, será conveniente que muestre los valores negativos en rojo para representar visualmente una baja de precios. Además, los nombres de las columnas generados por el Mashup Center no tienen sentido, debido a que el archivo csv no contiene una hilera de encabezados. De manera que será conveniente reemplazar esos nombres por otros que tengan más sentido. El Listado 12 muestra fragmentos del archivo XSLT de muestra stockColor.xsl incluido en el XSLTPlugin.zip descarga. Estas son las partes del archivo que realizan los cambios descriptos anteriormente para insertar la marca HTML.

Listado 12. Fragmento de stockColor.xsl
<xsl:template match="*" mode="rowChild">
                <xsl:choose> <xsl:when test="name()='col_A'" >
                <xsl:element name="Ticker"> <xsl:value-of select="." />
                </xsl:element> </xsl:when> ................
                <xsl:when test="name()='col_E'" > <xsl:element
                name="Change"> <xsl:choose> <xsl:when test="text()
                &lt; 0"> &lt;font color="#FF0000"
                face="courier"&gt;<xsl:value-of select="."
                />&lt;/font&gt; </xsl:when>
                <xsl:otherwise> <xsl:value-of select="." />
                </xsl:otherwise> </xsl:choose>
                </xsl:element> </xsl:when> ...............
                </xsl:choose> </xsl:template>

El fragmento del Listado 12 no muestra los enunciados xsl:template que se usan para ubicar los elementos de interés (elementos secundarios de la fila). Estos elementos secundarios de la fila pasan a la plantilla anterior para continuar el procesamiento. Los enunciados xsl:choose y xsl:when corresponden a los enunciados switch y caso de Java. Existe un caso (xsl:when) para cada uno de los elementos secundarios de la fila. Las columnas sin valores numéricos (por ejemplo, col_A) reciben un Nuevo nombre mediante la creación de un nuevo elemento que usa xsl:element y copia el valor texto. Las columnas numéricas que podrían ser negativas (por ejemplo, col_E) son verificadas usando un enunciado xsl:when para ver si el valor texto es menor o mayor que 0. Si el valor es negativo, se inserta la marca HTML para cambiar el color de fuente a rojo. Observe que es necesario salir de la marca insertada para que el DataViewer pueda interpretarla correctamente. Observe, además, que también se debe salir de los operadores de comparación para "menos que" y "igual o mayor a" dentro del enunciado xsl:if para poder cumplir con las reglas de XML.

Lo último que debe tomarse en cuenta antes de terminar se relaciona con algo que no fue considerado cuando tratamos el código del Listado 4. El casillero de texto HTML no escapa de las entidades XML &lt; y &gt; cuando el contenido del texto es asignado al mismo de manera programática (y no cuando el usuario lo ingresa directamente al casillero de texto). TPara asegurar que el archivo XSLT anterior se renderice de manera correcta al reeditarse, la implementación escapa el contenido del XSLT. Por ejemplo, &lt; cambia a &amp;lt; para que siga fuera cuando durante la visualización..


Conclusión

Usted acaba de recorrer la construcción de un complemento bastante complejo que involucra múltiples páginas de editor que usan las API del Mashup Center Versión 2. Para probar lo que usted ha aprendido en este artículo, puede ampliar el complemento actual del XLST para agregar soporte de parámetros. También, puede comenzar a usar la transformación XSLT descargando el proyecto del complemento e instalándolo en un servidor de la Versión 2 del Mashup Center.


Descargar

DescripciónNombretamaño
Sample plug-in filesXSLTPlugin.zip181KB

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt, Lotus
ArticleID=471823
ArticleTitle=Un complemento del IBM Mashup Center para realizar transformaciones XSLT
publish-date=03042009