While the Java source is the heart of the filter, the real power comes from the XSLT script (see Listing 2
). This is where the logic that governs the transformation resides. This script transforms any OBJECT
block in the page into three SCRIPT
tag blocks: one for the inclusion of a data handling class, one for the inclusion of a script containing a rendering function, and the last being one a function call into the rendering function.
Using the canned code for this filter, the XSLT script will be drawn from your server's /WEB-INF/filters directory.
As discussed earlier, the page's OBJECT block is replaced with three SCRIPT blocks. The first block links to an external file that contains a data handling class, KeyedArray.js (see Listing 4). The KeyedArray class is a very simple implementation providing associative array functionality. Unless you are customizing this code you'll never have to deal directly with this class.
The second block that links to an external file, MicrosoftEolasFilter.js (see Listing 3), contains a render function called writeObjectBlock.
The third and last is a tag block, which is a call to the rendering function. The rendering function, writeObjectBlock, receives all the information that was previously provided to the browser in the OBJECT block, and its subordinate PARAM tags, as arguments. These are passed to the function with KeyedArray instances. It doesn't do anything special really except to string them all back together as an OBJECT block, writing it back out with a document.writeshort and simple.
A quick snippet addition (see Listing 5) to your server's web.xml file is all that is needed to hook the filter into place, once all the files are copied into the correct directories. This snippet (two tag blocks) can technically be placed anywhere within the WEB-APP block.
|Figure 1. Popup Clock: This JSP page launches the Flash Clock movie. Thanks to the filter, this page doesn't rely on Eolas' patented method. |
The first block is the FILTER
block, it names the filter, identifies its classes file, and sets the parameters that will be made available to the filter. The parameters are defined in the subordinate INIT-PARAM
block. This is where the XSLT script is identified; if you have changed the location of the XSL file you will need to make certain that it is reflected here. The second block, the FILTER-MAPPING
block identifies it as part of the filter chain.
Remember that if you have multiple filters installed you may need to carefully investigate the order that they make their appearance in the configuration file. Their order in the file is their order of execution by the server. You want to be careful you are not feeding processed content from one filter that is unreadable to another filter, such as would be the case if the file compression filter ran before the MicrosoftEolasFilter.
You should see exactly what you'd expect, a page with a Flash movie (see Figure 1).
The real proof can be seen by viewing the page source with the browser.