An IBM Mashup Center plug-in for performing XSLT transformations

Mashup Center v2.0 Plug-in API introduction

Brief introduction

IBM Mashup Center comes with a data Mashup editor that can be used to combine and transform XML from multiple sources. This data mashup editor is easy to use, but in some cases it is more efficient to perform XML transformations using XSLT. You can learn how to benefit from both types of conversions, and this article shows you how to build an IBM Mashup Center plug-in that can perform XSLT transformations.

The previous two articles, "Extend the Reach", "IBM Mashup Center" and "an IBM Mashups Center plug-in to convert HTML to XML" describe how to extend The capabilities of IBM Mashup Center. These two articles are based on Mashup Center Version 1. This article focuses on new features in the Version 2 plug-in API, such as Basic and form-based authentication support. This article only discusses the obvious differences between version 1 and version 2 plug-in APIs.

This article assumes that you are familiar with the basics of writing IBM Mashup Center plug-ins. In particular, you should know how to program with Java™, JSP, JavaScript, and XSLT.

V2.0 Plug-in API changes summary

Different plug-ins may require different versions of the Java package. To provide the necessary isolation, starting with Version 2, each plug-in class is loaded by a separate class loader. Classes and plug-in-specific jars are stored in a plug-in-specific folder and are no longer replicated to the same location as in Version 1. The interaction with the framework is now done primarily through interfaces rather than concrete classes. For example, in Version 1, the Rendereditor method takes two specific classes RequestData and Entry as parameters. In v2.0, the class instance is changed to an interface, as shown in Listing 1.

Listing 1. Using an interface as a parameter

//　v1.1　public　ViewBean　renderEditor(RequestData　rdata,　Entry　entry)
　　 public　Object　renderEditor(IEditorContext　context)

The above changes have no obvious effect on the implementation of the plugin. The most noteworthy change in v2.0 is the implementation of the plug-in JSP. Because JSPs are loaded by the JSP class loader of the Web container, they do not have access to plug-in-specific (Viewbean) classes. Instead of using a property-specific getter method, the V2.0 plug-in JSP uses a generic name/value pair to get the property. This is demonstrated in a later section.

Setting up Eclipse projects

As described in section 6.1 of Version 2.0, application programming Interface Reference, during startup, server searches are placed in <webapplication>/web-inf/ A ZIP file in the plugins folder that contains Third-party plug-ins. This ZIP archive must have the following folder structure:

/client/plugins/plugin_dir-contains files for browsers, such as images and JavaScript files.

/server/plugins/plugin_dir-contains plug-ins manifest and plug-ins to display the interface of the file (JSP page).

/server/plugins/plugin_dir/classes-contains plug-in Java classes. This can be a folder hierarchy.

/server/plugins/plugin_dir/lib-contains the JAR files used by the plug-in (third party).

If you are familiar with the development of the v1.1 plug-in, you may notice that the classes and Lib folders are no longer placed under the Web-inf folder. To simplify the final build and packaging of plug-ins, you can use your favorite IDE to create a project that has a directory structure that matches the final ZIP archive. Figure 1 shows the layout of a sample Eclipse project.

Figure 1. Eclipse Project