Celtic News

Can't wait for ColdFusion 9 to be able to serialise your CFC objects?

Nah. Neither could I! So, I've written some code to serialise a CFC object into an XML string, and, of course, a function to rebuild your original CFC object from the xml. I've been using this for a while now and it seems to work in all cases. If you find differently, then please add a comment, or drop me a line.

I'm currently using it in place of the binary serialiser that should be delivered finally working in ColdFusion 9 for logging data. If we get a user error on our (public API) then I serialise the request and result objects and dump them to a database. I can then extract that data, re-create an exact copy of the object sent in, and repeat the exact same action that resulted in the error.

Our API can be access via Flas Remoting (so we pass in a CFC object), or from an external system. This maybe ColdFusion or .Net or whatever. We provide a webservice interface, which expects some rather complex objects as its input/output parameters. I've had no end of problems with both ColdFusion and .Net as the external system. ColdFusion received CFC outut object but converts them to Java objects. Whilst you can get at the data, it is certainyl not a copy of what was sent out, and certainly couldn't be sent back into our API in a later call... Similarly, .Net has issues: It won't handle a CFC object where one attribute is an array of another CFC object - it just reports the array as being empty.

So, to get around these problems, we've decided to provide a serialised API interface. Right now, since accepts XML serialises CFC objects, but when we get CF9, we'll add a binary serliased interface for external CF systems.

To use this, and external CF system simply takes copied of the CFC which define our data objects. They build the required objects, then serialise them as XML and send that to us. We can very quickly re-create the original CFC object and direct that to the same API that our Flex application uses. Similarly, we serialise the results and send them back; the calling system can then de-serialise the xml back to a native CFC object. Far, far better than dealing with the Java objects we've been used to.

Of course, thinsg are not so simple for external .Net (or whatever) systems. But, they simply build their XML data to the same spec as our CFC serialiser. They send that XML, and our API ends up with a CFC object. All very simple, and means we no longer have to care in the slightest what the external system is even though we are passing very complex nested CFC objects back and forth.

You can download serialiser.cfc here (just rename serialiser.txt to serialiser.cfc)

NOTE: serialiser.cfc also contains functions for native Java serialisation (The current CF8 ones, which doesn't support objects with array or date attributes)

And see a sample here

If you're interested, the code determines the type of each attribute in your CFC object, and encodes that into the XML. It then uses that to identify which CFC it needs to instantiate to rebuild the original attribute. This happens recursivelyhandlign any nested objects.