Welcome!

Guy Rish

Subscribe to Guy Rish: eMailAlertsEmail Alerts
Get Guy Rish via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: ColdFusion on Ulitzer, Apache Web Server Journal, Java Developer Magazine

CFDJ: Article

A Cold Cup O'Joe Part 7 of 8

A Cold Cup O'Joe Part 7 of 8

In Part 5 (CFDJ, Vol. 3, issue 8), "Java CFX Basics," I identified some shortcomings of the CFX model. In Part 7, I demonstrate a number of workarounds and solutions to these problems.

In many cases what I present here is viable across the board for all CFX types. However, this series deals specifically with Java interoperability, so I'll leave the modifications to you.

Complex Data Types
One of the critical problems with the CFX model is the inability to pass complex data types into and out of a CFX. Only simple types are possible - no structures, no arrays, and only a single query (using the QUERY attribute). This can be a considerable challenge when attempting to integrate with higher order applications that must work with large amounts of data using one of the "restricted" data types.

As it turns out, Allaire (before they became part of Macromedia) provided a powerful tool for data marshaling - Web Distributed Data eXchange (WDDX). WDDX has been a part of the regular offering in CFML since version 4.0, so encoding complex data types to be sent to a CFX is simple. It's a little more complicated on the other end though. Fortunately, as part of the WDDX SDK (www.openwddx.org), there's a Java class API that resolves most simple marshaling issues.

Using WDDX allows the CFML data types to be marshaled into analogous Java data types. CFML arrays become Java Vectors, CFML structures become Java Hashtables, and CFML queries become a specialized Java class from the WDDX API RecordSet.

To make the WDDX SDK work, an XML SAX parser is needed; I recommend Apache's Xerces parser (http://xml.apache.org). Once the WDDX SDK is downloaded and installed, it's important to include the WDDX SDK's JAR and the Xerces JAR in the ColdFusion Server's Java classpath setting. This can be done from the ColdFusion Administrator's Java Settings panel.

The methods of the WddxDeserializer class (see Table 1) are intended to convert WDDX packets into various Java data types.

Conversely, the methods of the WddxSerializer class (see Table 2) are intended to convert various Java data types into WDDX packets.

Deserializing
Making slight modifications to the "Hello, World" CFX that we've been using since Part 5, I've created a new tag called CFX_HelloAll (see HelloAll1.java). (The source code for this article can be downloaded from the CFDJ Web site, www.sys-con.com/coldfusion/sourcec.cfm.) This tag receives a WDDX serialized array of strings as a Names attribute. Retrieve the attribute in the normal CFX fashion by calling the getAttribute method of the custom tag's Request object. Since the array is serialized as a WDDX packet, it passes as a regular character string, which is completely legal in the CFX model. This does, of course, require the attribute to be deserialized within the custom tag. I've conveniently created a method called deserializeFromPacket, which does all the work (see Listing 1).

The method is fairly simple to use and in most cases works without a problem. The first few lines check the existence of the incoming argument. An interesting point in the method occurs on line 23, where the SAX parser to be used with the WDDX engine is set; this references a public and final property class called DEFAULT_SAXPARSER.

An attempt to create an instance of this class is made on lines 26-34 to verify that it's in the JVM's classpath. Then the packet is buffered in preparation for use on line 37. An instance of the WddxDeserializer is created, passing the classname of the SAX parser on line 40. On line 43 the deserializer is fed the buffered packet, then on line 45 the resultant object is returned to the calling logic.

The deserializeFromPacket is called in the tag's processRequest method in the case of the HelloAll tag. It expects the returned object to be a Vector (and casts it so), which it loops over, performing a write to the tag's Response object.

All this is called from the ColdFusion template, PacketExample1.cfm, which merely creates an array and populates it with three names, uses the CFWDDX tag to convert the array into a WDDX packet, and passes it when it calls CFX_HelloAll.

Serialization
Another rehash of the tag HelloAll2.java does pretty much what the previous version did, but instead of directly streaming out the messages, it loads them into a Vector. The Vector of strings is then serialized into a WDDX packet and returned to the calling logic, PacketExample2.cfm. The packet is then deserialized into a CFML array, which is looped over and displayed. The most interesting part in this new pairing is the serialization method in the CFX, serializeToPacket (see Listing 2).

This method is even simpler than the deserialization method. The WddxSerializer is instantiated on line 5. Lines 8-13 test the incoming object to be serialized and line 16 does the serialization, receiving the incoming object and the buffer instantiated on line 6 to hold the resultant packet. The contents of the buffer are returned to the calling logic on line 18.

End Tags
The CFX model has no capabilities to create custom tags with end tags, and there's no simple way around this challenge. There are rumors that ColdFusion's next generation platform has a solution, though that's little comfort to people running on current releases. While the CFX model is not prepared to deal with this, CFML is. Leveraging a CFML custom tag as a wrapper around a CFX tag allows for more advanced designs.

I've created a CFX that performs XSL transformations on an inputted character stream. This tag, Transformation.java, doesn't require any special construction to achieve its end-tag capability. This is accomplished through a CFML custom tag, Transformation.cfm, which wraps it. The ColdFusion template, TransformationExample1.cfm (see Listing 3), shows the custom tag combination in action. Lines 1-4 are the setup for using the custom tag, building the name of the XSLT stylesheet to use and the data file that's used to dynamically construct the XML. The tag opens on line 5, passing the dynamically constructed stylesheet name as an attribute; the body of the custom tag occupies lines 6-15; and the tag closes on line 16. To properly process all the variables, the body must be wrapped within a CFOUTPUT block. It's here that the XML is dynamically constructed, driven from the data drawn from the contents of the data file read on line 4.

The custom tag uses the ThisTag.ExecutionMode to determine whether it's processing. When the ExecutionMode is "start," the tag checks the incoming attributes. If the Source attribute is specified and there's no body, the CFX is called (this example is not shown), otherwise the tag body is processed. When the end tag is processed and the ExecutionMode is "end," the ThisTag.GeneratedContent is passed (as a regular String attribute) with the value of the Stylesheet attribute to the CFX.

Return Variables
Returning a value from a CFML-wrapped CFX requires an additional step. The regular way of doing this is through the CFX Response object's setVariable method. This remains true even with a CFML-wrapped CFX; the additional step results from the fact that the setVariable method is actually returning the value to the wrapping custom tag, not the top-level calling logic. This means that once the CFX returns the value, the CFML wrapper also needs to pass the value to its calling logic.

The ColdFusion template, TransformationExample2.cfm, sets up a condition for a returning variable as discussed. Much like the code in Listing 3, it dynamically constructs the stylesheet name, but uses a finished XML document to hand off to the custom tag and specifies a return variable name of "out".

<cfx_transformation stylesheet="#Attributes.Stylesheet#"
source="#Attributes.Source#" result="#Attributes.Result#">
<cfset "caller.#Attributes.Result#" =
Evaluate("Variables.#Attributes.Result#")>
This code snippet shows the two important lines from the CFML wrapper tag, and the incoming variable, Attributes.Result, being passed to the CFX as the Result attribute. Immediately after the CFX tag is called, the resulting variable is passed up the remaining layer to the calling logic. Since the CFX value will be passed into the Variables scope of the CFML custom tag, the CFML custom tag must create it and assign the value in the CFML tag's Caller scope.

Attributes Structure
One of the truly useful features of CFML custom tags constructed with CFML is the Attributes scope. This is another feature unavailable to tags written in the CFX model. Using the CFML-wrapped CFX strategy and WDDX serialization provide a kind of workaround to this shortcoming. To implement these example changes, I remade the XSL transformation tag set by creating new CFML tags, CF_TRANSFORMATION2 and CFX_TRANSFORMFORMATION2 (see Transformation2.cfm and Transformation2.java, respectively).

The alterations in the CFML custom tag center around two lines of code: the serialization of the entire Attributes scope into a packet and then passing it, and only it, to the CFX as the value of the Attributes Collection tag attribute.

<cfwddx action="cfml2wddx"
input="#Attributes#" output="packet">
<cfx_transformation2 attributes collection="#packet#">
The CFX alterations are a bit more involved. The inclusion of the deserializeFromPacket method used in the previous examples allows the serialized Attributes scope to be transformed into a Java Hashtable (see Listing 4).

Beyond these simple changes the rest of the tags remain the same. Using these tags from a user standpoint is identical to using the previous version, with the exception of its name; this is reflected in the ColdFusion template, TransformationExample3.cfm.

Wrapping It Up
There are a number of ways to overcome the immediate shortcomings of the CFX model. Combining CFML with the CFX model, Java's extensive libraries, as well as other tools and technologies, like WDDX, provide creative ways to do this. The techniques demonstrated in this article are for general use and may be incorporated easily enough into regular custom tag construction. There are, as I'm certain will be discovered through further study, specialized techniques that can be utilized from time to time. Further, when ColdFusion's next generation is released, the enhanced custom tag models and new technologies will extend this even more.

More Stories By Guy Rish

Guy Rish is a ColdFusion and .NET developer at Vente as well as President at Gestaltech. He is an active developer and writer for various languages and technologies, and has contributed work in books on ColdFusion MX, Flash MX, and Dreamweaver MX. He blogs at ccoj.coldfusionjournal.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.