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.

// 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.

Volver arriba

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.

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.

<?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.

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.

Volver arriba

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.

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.

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.

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.

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!

Volver arriba

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.

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.

Volver arriba

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.

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.

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.

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.

Volver arriba

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.

<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.

<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!

<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.

<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, < cambia a < para que siga fuera cuando durante la visualización..

Volver arriba

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.

Volver arriba

Descargar

Información sobre métodos de descarga

Recursos

Aprender

• Para aprender los conceptos básicos acerca de la creación de un complemento para IBM Mashup CenterV1., lea "Extend the reach of data for IBM Mashup Center (Cómo extender el alcance de los datos para IBM Mashup Center)" (developerWorks, agosto de 2008).Para la Versión 2.0 de IBM Mashup Center o posterior, use este artículo.
  
  
• para un tratamiento más profundo de la creación de un complemento para IBM Mashup CenterV1.1, lea "An IBM Mashup Center plug-in to convert HTML to XML (Un complemento de IBM Mashup Center para convertir HTML en XML)" (developerWorks, agosto de 2009).
  
  
• El Capítulo 6 de IBM Mashup Center Version 2.0 Application Programming Interface Reference (Referencia a las interfaz de programación de aplicaciones de IBM Mashup Center Versión 2.0) es la documentación oficial para los API del complemento de IBM Mashup Center.
  
  
• "Manipulating data with XSL (Cómo manipular datos con XSL)" (developerWorks, octubre de 2001) es un buen tutorial de introducción a XSLT.
  
  
• Para aprender acerca de Dojo, consulte la página web de la Documentación oficial de Dojo .
  
  
• En el área de Gestión de la Información de developerWorks, obtenga los recursos necesarios para avanzar en sus conocimientos prácticos de los productos de IBM Information Management.
  
  

Obtener los productos y tecnologías

• Para obtener una experiencia práctica con IBM Mashup Center, visite Lotus greenhouse.
  
  
• Descargue una versión de prueba gratuita de IBM Mashup Center desde developerWorks.
  
  
• También puede accede a Mashup Center en Amazon Elastic Compute Cloud(Nube de computación elástica de Amazon).
  
  

Comentar

• Participar en el foro de debate.
  
  
• Vea los blogs de My developerWorks e involúcrese en la comunidad developerWorks .
  
  

Sobre el autor

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Introducción
• Breve resumen de los cambios realizados a la API del complemento de la v2.0
• Configuración de un proyecto de Eclipse
• Implementación del editor
• MétododisplayPreviewPage
• Implementación de la generación de feeds
• Utilización de la muestra
• Conclusión
• Descargar
• Recursos
• Sobre el autor
• Comentarios