Compound Theory

v2.0

Categories

  1. Transfer
  2. ColdFusion
  3. Java
  4. Conduit
  5. JavaLoader
  6. ColdDoc
  7. AsyncHTTP
  8. OO Analysis and Design
  9. Flex
  10. XML / XSL
  11. XHTML / CSS
  12. Ubuntu
  13. Eclipse
  14. Oracle Database
  15. Usability / UI Design
  16. cf.Objective
  17. webDU
  18. Captcha
  19. Melbourne CFUG
  20. Martial Arts
  21. Random Things

Recent Posts

Projects

Instant Message

Instantly grab my attention...

Recent Comments

14 December 2008 09:58 AM 5 Comments

Conduit: The ColdFusion Adapter for BlazeDS

This project started with writing the translation layer for doing Transfer to Flex communication, I ran into a pretty nasty bug in ColdFusion's remoting implementation, and then ended up in a place that solves all these problems, and is incredibly flexible and powerful to boot!  Quite the round trip, but well worth it in the end.

Conduit requires that you set up BlazeDS on your machine, as well as install the conduit.jar file, and some CFCs as well.  I'm not going to go into too much details here, as you can read about in the Library Installation section of the documentation.

To configure Conduit, we open up our remoting-config.xml, and we add the Conduit adapter to the <adapters> section:

<adapter-definition id="conduit" class="com.compoundtheory.conduit.adapters.ColdFusionAdapter"/>

And now we continue by adding a new Destination to our remoting-config.xml, which we will then call from Flex via RemoteObject (examples of the configuration are provided in the downloads).

<destination id="Conduit">
    <channels>
        <channel ref="my-cfamf" />
    </channels>
    <adapter ref="conduit" />
    <properties>
        <source>*</source>
        <cfcs>
            <!--
            Whether or not reload the CFCs below on each request.
            Useful for debugging when building new invokers,serialisers
            or deserialisers
            -->

            <reloadcfcs>false</reloadcfcs>
            <!--
            The CFC that invokes the remote method call
             -->

            <invoker>conduit.core.CFCInvoker</invoker>
            <!--
            Translates CF=>AS3
             -->

            <serialiser>conduit.core.CFSerialiser</serialiser>
            <!--
            Translates AS3=>CF
             -->

            <deserialiser>conduit.core.CFDeserialiser</deserialiser>
        </cfcs>
    </properties>
</destination>

The id of the destination can be whatever you like, but we started with 'Conduit', so we would know what we are calling from Flex.

The <adapter> is specified to use the conduit adapter, rather than the default cf-object adapter.

We then set a series of properties, most important of which are setup within the <cfc> section.  This section controls what CFCs are called upon to perform various duties within the ColdFusion <=> Flex communication process.

Just to emphasise this point - this means that the majority of the heavy lifting done by Conduit is done with ColdFusion code.  This makes it really easy to extend, change, manipulate or debug.  It gives you almost complete control over the AS3<=>CF translation process, without you having to know much about Java at all (I will admit there are some Java classes involved).

We can see from there are three CFCs that the Conduit adapter has configured for it.

The <invoker>
This is the CFC that does the actual method calling.  In the instance of the conduit.core.CFCInvoker that comes with Conduit, all it does is create an instance of the CFC that has been requested in the <RemoteObject>'s source attribute, and calls the passed with method name and any parameters that were passed down from Flex.

The code looks something like this (just to show you how simple it is):

<cffunction name="execute" hint="Creates a cfc, and invokes a methodon it" access="public" returntype="any" output="false">
    <cfargument name="source" hint="the cfc source" type="string" required="Yes">
    <cfargument name="methodName" hint="the name of the method" type="string" required="Yes">
    <cfargument name="params" hint="the parameters to pass in" type="any" required="Yes">
    <cfscript>
        var local = {};
        var object = createObject("component", "#arguments.source#");
    </cfscript>

    <cfinvoke component="#object#" method="#arguments.methodName#"argumentcollection="#arguments.params#"returnvariable="local.return">

    <cfif StructKeyExists(local, "return")>
        <cfreturn local.return />
    </cfif>
</cffunction>

Pretty straight forward, no?

The <serialiser>

The job of this CFC is to take whatever is returned from the <invoker> and translate it into whatever you want to return back to Flex.  Since BlazeDS handles the AMF conversion part of it for us, the conduit.core.CFSerialiser only really needs to convert CFCs in Actionscript objects, set all their properties correct, and we are good to go.

The <deserialiser>

The deserialiser CFC's job it to take the incoming parameters that come down from a Flex RemoteObject call, and translate them into something usable for the <serialiser> CFC.

Again, since BlazeDS does a lot of the heavy lifting, the conduit.core.CFDeseriailser's main job, is to convert Actionscript Objects into their appropriate CFCs, and set all their properties correctly.

Changing how things work
 
While there are plans to put some interesting enhancements for Conduit to provide above and beyond what ColdFusion remoting already does, the real power of Conduit comes from being able to write your own custom Invoker, Serialiser or Deserialiser.

Say for example, when we send information from ColdFusion to Flex, we want to reverse every Simple value (String, date, numeric) that we come across.  Don't ask me why you would want to do this ;o), maybe you just like messing with your co-workers.

First thing we need to do is write our own custom CFSerialiser.cfc.  For this example, I'm going to reuse the conduit folder I would have setup, which already has a /conduit ColdFusion mapping pointing to it, and create a new folder called reverse inside it.

So I create a new component, under /conduit/reverse, and call in CFReverseSerialiser.cfc, and make it extend conduit.core.CFSerialiser.

We will now overwrite the translate method, which handles what data gets converted, and how, depending on its data type.

The code would look something like this:

<cfcomponent output="false" extends="conduit.core.CFSeriaiser" hint="Component for serialising CF=>AS3, in reverse">

<cffunction name="translate" hint="translation function for objects,reverses simple values" access="private" returntype="any"output="false">
    <cfargument name="object" hint="the object to serialise" type="any" required="no">
    <cfargument name="cache" hint="local reference cache for cyclic graphs" type="any" required="Yes">
    <cfscript>
        if(isSimpleValue(arguments.object)
        {
            >//if it's simple, then reverse it!
            return reverse(arguments.object);   
        }
        else
        {
            return super.translate(argumentCollection=arguments);
        }
    </cfscript>
</cffunction>
</cfcomponent>

And we can configure a special 'ConduitReverse' destination for anyone who wants reversed Strings in their code:

<destination id="ConduitReverse">
    <channels>
        <channel ref="my-cfamf" />
    </channels>
    <adapter ref="conduit" />
    <properties>
        <source>*</source>
        <cfcs>
            <reloadcfcs>false</reloadcfcs>
            <invoker>conduit.core.CFCInvoker</invoker>
            <serialiser>conduit.reverse.CFReverseSerialiser</serialiser>
            <deserialiser>conduit.core.CFDeserialiser</deserialiser>
        </cfcs>
    </properties>
</destination>


As you can see, we can do almost anything we want to the communication process, simply by extending the core components (or even writing brand new ones) and because its at a low level, its almost completely seamless to those who are writing the ColdFusion and/or Flex code. That being said, its open source, so we can add extra logging and/or debugging as we need.  No more failing silently!

Trying it out

This is still Alpha code, and there is a lot of logging currently in it, but there is enough there for you to start playing.  Code is in SVN, and daily builds are available from the Google Group (saves you having to compile the .jar file).  The documentation is slowly getting fleshed out, but there is enough there to get started.

I am more than happy to get code contributions, and/or ideas for how the to expand on the current ColdFusion remoting feature so send through whatever you have.

I hope you enjoy Conduit!
01 December 2008 08:16 AM 1 Comment

ColdFusion AMF Serialiser inserts 'null' values into a cyclic Object graph... what the?

When writing the Flex <=> Transfer integration, coming across a cyclic object graph is pretty common, as onetomany compositions generate a bi-directional relationship between 2 objects.  I.e. A Parent knows about its children, and children know about their parents.

It is also quite possible for situations to occur, where Object A knows about B, B knows about C, and C knows about A, and therefore having a complete circle.

What confused me no end pretty much all day yesterday, is that when trying to send such an Object data structure up to Flex, theAMF Serialiser, doesn't send it up correctly, instead, it decides to replace one Object value with 'null', in an attempt to break the circle.

To give you an example, I set up a CFC, which had a UUID for identity, and a reference to a child (download the code below to have a look), and an appropriate VO on the Flex side.

I then sent this to Flex, as a cyclic graph of objects, like so:

<cfcomponent output="false">
    <cffunction name="getRecursive" hint="returns a circular CFC structure" access="remote" returntype="flexrecursive.Recursive" output="false">
        <cfscript>
            var a = createObject("component", "flexrecursive.Recursive");
            var b = createObject("component", "flexrecursive.Recursive");
            var c = createObject("component", "flexrecursive.Recursive");

            a.setChild(b);
            b.setChild(c);
            c.setChild(a);

            return a;
        </cfscript>
    </cffunction>
</cfcomponent>

So, like above, A knows about B, B knows about C, and C knows about A.

I then passed this up to Flex, and logged whether or not the children in the collection of Objects was null.

In theory, I should be able to run the following code quite happily, without fear of a NullPointerException:

//rec is the returned objects to Flex
trace(rec.id);
trace(rec.child.id);
trace(rec.child.child.id);
//this should output the same id as the 1st line, as they are the the same object
trace(rec.child.child.child.id);

But what happens when I run my test code is:

* retrieved recursive CFCs, should be 3 items in a recursive graph:
rec.id:
id: F47E1371-C2A7-D498-1F6497AA3F3AEBC8
rec.child.id:
id: F47E1375-A404-D99C-50675EB12C98F9B9
rec.child.child.id:
id: F47E1378-A4AA-57E4-192C2A59D73A9832
rec.child.child.child.id:
This child is null!!!

The Serialiser simply replaces 'null' for the last place in the graph, rather than having a reference to the first Object!

I've run this code through Charles, and have confirmed this is also the structure CF sends in AMF as well.

Looking at the AMF Specification, I read:

'Objects can be sent as a reference to a previously occurring Object by using an index to
the implicit object reference table. Further more, trait information can also be sent as a
reference to a previously occurring set of traits by using an index to the implicit traits
reference table.'


So it should be possibly to handle a cyclic graph of objects, as you could simply insert a reference to a previously serialised object... so what gives ColdFusion? How come this weird and wacky behaviour?

This test was run with ColdFusion 8.01, and Flex 3.2.

If you wish to download my CF and Flex test bed, you can from here.

23 November 2008 06:22 PM 0 Comments

CodexWiki goes open Beta!

For a while now, Luis Majano and I have been working on CodexWiki , a ColdBox , Transfer and ColdSpring powered wiki.

The features in it have come together really nicely, including one of the slickest wiki editors I have ever seen, and it has finally gotten to the point where there was no point in keeping it in private beta any longer.

If you are interested in checking out go to http://www.codexwiki.org , and if you wander over to the ColdBox blog , you can see some great screenshots.

Its been great working with Luis, and we have many more ideas for this wiki in the coming future! Watch out :oD

23 November 2008 01:02 PM 5 Comments

ColdDoc 0.1 Released

ColdDoc 0.1 is finally ready as a release version.

ColdDoc is a port of JavaDoc for ColdFusion, and generates static .html files that display API information for a collection of CFCs.

ColdDoc was initially written to output the API documentation for Transfer, which can be seen here .

The benefits of outputting documentation to static html files, rather than doing it dynamically include:

  • Less processing at run time 
  • Documentation can be linked to, without fear of page names and/or anchors changing
  • The ability to generate API details such as Direct known subclasses and Method Overrides information which would be too expensive to determine at run time.

Currently ColdDoc only supports a single root path, and is missing some JavaDoc implementations, such as a Index page, and Interface documentation, and can only run on ColdFusion 8.

ColdDoc can be downloaded from here .

12 November 2008 10:31 AM 0 Comments

Melbourne CFUG - 20th of November

The last Melbourne CFUG for the year!

Location:
NGA.net, Level 2, 17 Raglan St, South Melbourne
Map: http://link.toolbot.com/google.com/73016

When:
November 20, Meeting starts at 7:00, so get there before hand (doors
open at 6:30).
   
Agenda:
Steve Onnis talks about virtualisation

Steve will be presenting on server virtualisation using VMWare.  VMWare allows you to create
virtual operating systems that run independent of your main operating systems giving you the
flexibility to create development environments for testing.

Demonstrating the setup process and vm tools, you will gain an understanding of what virtualisation
is and an insight into what virtualisation can do for you.

If you are going to attend, please RSVP to mark (dot) mandel (at) gmail.com.

Only those that RSVP are eligible for the door prizes, so make sure you apply!

See the CFUG Melbourne Calendar at:
http://www.cfcentral.com.au/Events/index.cfm

Or add to your Google Calendar - search for 'CFUG Melbourne'.

As per usual, we'll grab pizza during the evening, so we have
something to scoff down!

Look forward to seeing you all there.